+ All Categories
Home > Documents > GSA Leitfaden zur Spezifizierung/Ausschreibung ... · Ausschreibung interoperabler...

GSA Leitfaden zur Spezifizierung/Ausschreibung ... · Ausschreibung interoperabler...

Date post: 06-Sep-2019
Category:
Upload: others
View: 2 times
Download: 0 times
Share this document with a friend
129
Freier Download von www.big-eu.org VDI-TGA/BIG-EU Leitfaden zur Ausschreibung interoperabler Gebäudeautomation auf Basis von DIN EN ISO 16484-5 Systeme der Gebäudeautomation – Datenkommunikationsprotokoll (BACnet) Enthält die aktualisierte Übersetzung des Handbuches NISTIR 6392 mit Anpassung an die VOB und den Markt in Mitteleuropa Ausgabe Okt. 2009 (V2.8a) NISTIR 6392, GSA Guide to Specifying Interoperable Building Automation and Control Systems using ANSI/ASHRAE Standard 135-1995, BACnet (Nov. 1999) (1. de. Übersetzung 2001) © B.I.G.-EU / VDI-TGA 2009 HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 1
Transcript

Freier Download von www.big-eu.org

VDI-TGA/BIG-EU

Leitfaden zur Ausschreibung

interoperabler Gebäudeautomation

auf Basis von DIN EN ISO 16484-5

Systeme der Gebäudeautomation – Datenkommunikationsprotokoll

(BACnet)

Enthält die aktualisierte Übersetzung des Handbuches NISTIR 6392

mit Anpassung an die VOB und den Markt in Mitteleuropa Ausgabe Okt. 2009

(V2.8a)

NISTIR 6392, GSA Guide to Specifying Interoperable Building Automation and Control Systems using ANSI/ASHRAE Standard 135-1995,

BACnet (Nov. 1999)

(1. de. Übersetzung 2001)

© B.I.G.-EU / VDI-TGA 2009

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 1

Vorwort der Verfasser NISTIR 6392 Wenn ein interoperables System der Gebäudeautomation mit dem BACnet Protokoll zum Einsatz kommen soll, gibt dieses Handbuch eine Hilfestellung für die Planung und die Erstellung der Leistungsverzeichnisse. Dieses Dokument zeigt auf, was bei der Planung einer interoperablen Gebäudeautomation beachtet werden muss und gibt dazu Empfehlungen. Behandelt werden nur die Punkte, welche bei der Ausschreibung heterogener Systeme zusätzlich zu beachten sind. Die Aussagen gelten ausschliesslich für die Kommunikation und Interoperabilität von Systemen und Geräten der Gebäudeautomation, wenn sie BACnet benutzen. Übersetzt mit freundlicher Genehmigung durch die Autoren: Steven T. Bushby Building and Fire Research Laboratory Gaithersburg, MD H. Michael Newman Cornell University Ithaca, NY Martin A. Applebaum Ess Engineering Inc. Tempe, AZ Anmerkung zur vorliegenden zweiten Auflage des BACnet Leitfadens Das vorliegende Handbuch "Leitfaden zur Ausschreibung interoperabler Gebäudeautomation auf Basis von DIN EN ISO 16484-5" versteht sich als Ergänzung zu den für GA-Systeme gültigen Normen (Auflistung gem. VDI 3814-2 : 2004), zur VOB/C (siehe DIN 18386) und zu den weiteren Richtlinien des VDI für die Planung und Ausschreibung von Systemen der Gebäudeautomation. Die Richtlinienserie VDI 3814, ergänzt die GA-Weltnorm widerspruchsfrei um lokale Belange. Mit der neuen ATV (Allgemeine Technische Vertragsbedingungen) VOB/C DIN 18386:10/2006 werden in Ergänzung des BGB-Werkvertragsrechts für das Bauwesen die bei GA-Projekten (mindestens) zu beachtenden Normen und Richtlinien festgelegt. Das GAEB STLB-Bau LB 070 (im Anhang E) wird derzeit im Hinblick auf BACnet überarbeitet. Zu gegebener Zeit wird der BACnet Leitfaden auf dieses Werk eingehen. Das STLB-Bau hat insbesondere Gültigkeit für Projekte der öffentlichen Hand. Das neue Fachbuch "BACnet Gebäudeautomation 1.4", 2. Aufl. 2006 (ISBN 3-922420-09-5) vermittelt weitergehende, detaillierte Informationen über das Gebäudeautomation mit BACnet. Es ergänzt auf ideale Weise diesen Leitfaden. (Weitere Informationen unter http://www.cci-promotor.de/ ) Zu diesem Leitfaden gehört das VDI / BIG-EU Dokument "Begriffe zum BACnet-Leitfaden".

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 2

Revisionen: V2.0 (2004-08): Änderung "object type" = "Objekttyp", weil schon weit verbreitet eingeführt. V2.1 (2004-09): Änderung "device type" = Device-Typ". V2.2 (2004-10): Änderung "VOB" in Vergabe- und Vertragsordnung; Titel-Korr. in 9.1, 9.2 V2.3 (2005-05): Korrektur "Native BACnet", 1.2 aktualisiert, 1.5.2 D) und 4.2 aktualisiert, Erg. C.3.2; Ergänzung Anhang F (Checkliste) V2.4 (2005-05): Nochmalige Korrektur "Native BACnet", und BIBBs A1.12 – A1.16 korrigiert V2.5 (2005-07): Vorwort angepasst, 1.3 ergänzt, Kapitel 8 überarbeitet, GA-Funktionsliste nach ISO Checkliste im Anhang erneuert. V2.6 (2005-10): Aktualisierung C4 (STLB-Bau) und Anhang E: 2. GA-Funktionen V2.7 (2006-09): Aktualisierung Kapitel 4 (Tabelle) und C4 Normung V2.8 (2006-09): Aktualisierung Vorwort, Kapitel 1.3 und 1.4; in Anhang A eingefügt: BIBBs Zusammenfassung als „Handliste“ V2.8 (2009-10): Korrektur der BIBB-Tabelle (ASC ohne SCHED) Seite 94

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 3

Vorwort der Übersetzer (erste Auflage) Zum Zeitpunkt der Erstellung des Original Dokuments NISTIR 6392 (National Institute of Standards and Technology and Technology) des U.S. Department of Commerce, erstellt für die U.S. General Services Administration war BACnet der ANSI/ASHRAE Standard 135:1995. Bei der ersten Übersetzung bestanden Unterschiede von der Originalversion des BACnet Protokolls mit den Dokumenten der zuständigen europäischen Normungsgremien. Die damaligen Abweichungen sind in Anhang D aufgezeigt. Danksagung: Die BACnet Interest Group Europe e.V. bedankt sich bei folgenden Mitgliedern, die sich an der Übersetzung des Handbuches NISTIR 6392 in die deutsche Sprache beteiligt haben: Franz E. Fritz JCI Regelungstechnik GmbH [email protected] Karl Leber ISC Computerautomation GmbH [email protected] Hans R. Kranz VDI ehemals Siemens Building Technologies AG [email protected] HAK Ingenieurberatung, Forst/Baden Christian Müller Honeywell AG [email protected] Markus Ruf ehemals Ebert-Ingenieure [email protected] Citect Software Vertriebsgesellschaft mbH Panjörg Salzmann ehemals Amann GmbH [email protected] Hans Symanczik Kieback & Peter GmbH & Co. KG [email protected] Siegfried Weikmann Planungsgruppe M+M AG [email protected] Anmerkung zur Übersetzung Die Übersetzung des Originaldokuments war deshalb nicht einfach, weil ein allgemein anerkannter Wortschatz für Gebäudeautomation im Allgemeinen und für das Kommunikationsprotokoll im Besonderen noch fehlte. Seit 2004 gibt es den offiziellen Wortschatz mit der Weltnorm für Gebäudeautomation DIN EN ISO 16484-2. Die Weiterführung dieses Glossars für die anderen Teile der GA-Weltnorm kann beim Autor in der aktuellsten Fassung angefordert werden: [email protected] (Siehe auch Vorwort der 2. Ausgabe).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 4

Vorwort für die vorliegende deutsche Fassung (zweite Auflage) Im Auftrag der BIG-EU und des VDI-Wissensforum wurde die Übersetzung des GSA-Leitfadens zur Ausschreibung interoperabler Gebäudeautomationssysteme auf der Basis des ANSI/ASHRAE BACnet Standards 135-1995, für den VDI – BIG-EU Kurs Gebäudeautomation mit BACnet auf die aktuellen, in Europa und Deutschland gültigen Normen, Richtlinien und die Vergabe- und Vertragsordnung für Bauleistungen (VOB, früher Verdingungsordnung) angepasst. Grundlage ist jetzt die Internationale Norm DIN EN ISO 16484-5:Dez. 2003, Systeme der Gebäudeautomation – Datenprotokoll. BACnet wurde im Rahmen einer parallelen Abstimmung der ISO- und CEN- Staaten als einzige Weltnorm der Datenkommunikation für interoperable Systeme der Gebäudeautomation einstimmig bestätigt. Das heisst auch, dass die EN ISO 16484-5 (BACnet) weitere Normprotokolle für die Datenübertragung (z.B. LonTalk oder Ethernet/IP) und für die Dateninterpretation (z.B. KNX mit den EIBA-Interworking-Standards „EIS“) umfassen kann. Die die Integration des normativen KNX (EIB)-Mapping dient zur standardisierten Integration von KNX (EIB) Systemen nach EN 50090 in BACnet-Systeme. Mit der Erarbeitung der Weltnorm für Gebäudeautomation bei ISO und CEN wurde auch ein gemeinsames Vokabular erarbeitet, welches im Oktober 2004 als DIN EN ISO 16484-2 veröffentlicht wurde. Die hier dargelegten Begriffe beziehen sich auf diese Weltnorm der GA. Die Neuauflage dieses Handbuchs für die Planung und Ausschreibung von GA-Systemen verwendet die Begriffe der neuen Norm dort, wo deren Anwendung als geboten erscheint. Allerdings sind manche Übersetzungen noch nicht gefestigt, z. B. en: property= de: Property, siehe Hinweise in 1.3. Die Protokollpflege für BACnet erfolgt seit 2004 im Rahmen einer Wartungsvereinbarung (Maintenance Agency) mit ISO und CEN durch ASHRAE SSPC 135 (die deutschen DIN-Vertreter in diese „MA“ sind Prof. Peter Fischer und Hans Kranz). Das vorliegende Handbuch versteht sich als Ergänzung zu den für GA-Systeme gültigen Normen (Auflistung gem. VDI 3814-2 : 2005), zur VOB/C (siehe DIN 18386:10/2006) und zu den weiteren Richtlinien des VDI für die Planung und Ausschreibung von Systemen der Gebäudeautomation. Die Beispiele zum GAEB STLB-Bau LB 070 im Anhang E haben insbesondere Gültigkeit für Projekte der öffentlichen Hand, es ist jeweils die aktuelle Fassung, erhältlich vom Beuth Verlag, Berlin, zu verwenden. Gebäudeautomation umfasst entsprechend den Kostengruppen der Baukostennorm DIN 276 (Vorlage für neue Ausgabe ab 2006, wesentliche Änderungen kursiv gesetzt): Kgr.: 480

Gebäudeautomation

Kosten der anlagenübergreifenden Automation

481 Automationssysteme Automationsstationen mit Bedien-, und Beobachtungseinrichtungen, GA-Funktionen, Anwendungssoftware/Lizenzen, Sensoren und Aktoren, Schnittstellen zu Feldgeräten und anderen Automationseinrichtungen

482 Schaltschränke Schaltschränke zur Aufnahme von Automationssystemen (KG 481), mit Leistungs-, Steuerungs- und Sicherungsbaugruppen, einschließlich zugehöriger Kabel und Leitungen, Verlegesysteme, soweit nicht in anderen Kostengruppen erfasst

483 Management- und Bedieneinrichtungen

Übergeordnete Einrichtungen für GA und Gebäudemanagement mit Bedienstationen, Programmiereinrichtungen, Anwendungssoftware/Lizenzen, Servern, Schnittstellen zu Automationseinrichtungen und externen Einrichtungen

484 Raumautomationssysteme Raumautomationsstationen mit Bedien- und Anzeigeeinrichtungen, Schnittstellen zu Feldgeräten und anderen Automationseinrichtungen

485 Übertragungsnetze Netze zur Datenübertragung, soweit nicht in anderen Kostengruppen erfasst

489 Gebäudeautomation, sonstiges

Dipl.-Ing. Hans R. Kranz VDI, Forst / Baden Im September 2006

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 5

Inhaltsverzeichnis Seite Vorwort der Verfasser NISTIR 6392 ........................................................................................................ 2

Vorwort für die vorliegende deutsche Fassung (zweite Auflage)............................................................. 5

Anmerkung zum Vorwort für die vorliegende deutsche Fassung (zweite Auflage) ................................. 9

0 Zweck dieses Handbuches ............................................................................................................. 10

1 BACnet Systemstruktur und Begriffe .............................................................................................. 10 1.1 Allgemeines ............................................................................................................................. 10 1.2 Das BACnet Modell der Gebäudeautomation.......................................................................... 11 1.3 Hinweise zur deutschen Übersetzung ..................................................................................... 12 1.4 Verwendete Begriffe und Definitionen nach DIN EN ISO 16484-2 ......................................... 15

1.5 Hinweise zu den Kommunikationsfunktionen.............................................................................. 16 1.6 Kommunikationspfade in GA-Systemen nach DIN EN ISO 16484-2 ...................................... 19

2 Spezifikation interoperabler BACnet-Systeme................................................................................ 20 2.1 Ziel von BACnet ....................................................................................................................... 20 2.2 Festlegen der Anforderungen an interoperable Systeme........................................................ 20

3 Interoperabilitätsbereiche – IOB ..................................................................................................... 21 3.1 Definition .................................................................................................................................. 21 3.2 DS - Gemeinsame Datennutzung (en: data sharing) .............................................................. 21 3.3 AE - Alarm- und Ereignisverarbeitung ..................................................................................... 23 3.4 SCHED - Zeitplan (en: scheduling).......................................................................................... 24 3.5 T - Trendaufzeichnung (en: trending) ...................................................................................... 25 3.6 DM - Device und Netzwerk-Management................................................................................ 26

4 Anwendung von BACnet-Objekten ................................................................................................. 28 4.1 Beschreibung der BACnet Objekttypen................................................................................... 28 4.2 BACnet Objekttypen und GA-Funktionen der EN ISO 16484-3 bzw. VDI 3814-1:2004 ......... 29 4.3 Tabellarische Übersicht BACnet-Objekte – GA-Funktionen.................................................... 30 4.4 Adressierungs- (Namens-) Konventionen................................................................................ 33 4.5 Systemengineering und Diagnose über BACnet Dienste........................................................ 34 4.6 Benutzung der Objekt-Beschreibung....................................................................................... 35 4.7 Anmerkung zu Kommunikations-Objekttypen ......................................................................... 35 4.8 Erzeugen von BACnet Objekten im laufenden Betrieb............................................................ 38

5 Anwendung von BACnet Diensten.................................................................................................. 39 5.1 Prioritätensteuerung für interoperable Aufträge/Befehle ......................................................... 39 5.2 Ereignis Management in BACnet Systemen............................................................................ 40 5.3 Festlegung der Benutzer-Zugriffskontrolle............................................................................... 42 5.4 Verarbeitung von Wertänderugen – COV................................................................................ 42 5.5 Zeitsynchronisierung................................................................................................................ 43

6. GA-Netzwerk Architektur ............................................................................................................. 44 6.0 GA-Netzwerke.......................................................................................................................... 44 6.1 Netzwerk Struktur .................................................................................................................... 45 6.2 Auswahl der LAN (Local Area Network) Option ..................................................................... 46 6.3 Strukturierte Vorgabe von MAC-Adressen .............................................................................. 51

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 6

6.4 Netzwerknummerierung........................................................................................................... 53 6.5 Device-Objekt Adressierung .................................................................................................... 54 6.6 Verwendung von BACnet mit Internet-Protokollen .................................................................. 55 6.7 Routervernetzung von mehreren BACnet-Netzwerken ........................................................... 58 6.8 Datensatz-Segmentierung ....................................................................................................... 58 6.9 Gateway-Anschluss zu proprietären Systemen....................................................................... 58

7. Hinweise für die Planung und Ausführung von BACnet Systemen............................................. 61 7.0 Allgemeines ............................................................................................................................. 61 7.1 Planung und Vergabe .............................................................................................................. 61 7.2 Montageplanung ...................................................................................................................... 62 7.3 Protokollanalysator und Inbetriebnahme ................................................................................. 63 7.4 Dokumentation und Schulung.................................................................................................. 64

8. Rechtliche Bewertung öffentlicher Ausschreibungen.................................................................. 66 8.1 Rechtliche Aspekte in Bezug auf die VOB............................................................................... 66 8.2 Besonderheiten in Bezug auf spezielle Produkte oder "Technologien" .................................. 66 8.3 Leistungen für Gebäudeautomation nach VOB....................................................................... 67 8.4 VOB/B § 8 und 9, Gründe für die Kündigung des Vertrages................................................... 67 8.5 Anforderungen an ein Leistungsverzeichnises nach VOB/A § 9............................................. 67 8.6 Aufteilung in Fachlose und Änderung der zu erbringenden Leistung...................................... 68 8.7 Einzukalkulierende Nebenleistungen....................................................................................... 68

9 Rechtliche Aspekte der Systemintegration.................................................................................. 69 9.1 Einleitung ................................................................................................................................. 69 9.2 Verantwortung für Sicherheit ................................................................................................... 69 9.3 Verträge und Versicherungen.................................................................................................. 69 9.4 Die geschuldete Leistung (und Funktions- oder Meldungsversagen) ..................................... 70 9.5 Die vertragliche Haftung im Falle von Fehlfunktion, Störung, Personenschaden ................... 70 9.6 Funktion des "integrierten Gesamtsystems"............................................................................ 70 9.7 Versicherungsaspekte ............................................................................................................. 71 9.8 Die wesentlichen Anforderungen............................................................................................. 71 9.9 Gesetzliche Haftung, verschuldensunabhängig ...................................................................... 71 9.10 Pflichten des Systemintegrators oder Errichters.................................................................. 72 9.11 Gesetzliche Haftung, verschuldensabhängig....................................................................... 73 9.12 Normen (speziell fürs Gefahrenmanagement)..................................................................... 73 9.13 Grundlagen der Sicherheit ................................................................................................... 74 9.14 Hilfestellung.......................................................................................................................... 74

Anhang A BACnet Interoperability Building Blocks (BIBBs).............................................................. 75 A.0 BIBBs Zusammenfassung als „Handliste“ ............................................................................... 75 A.1 Data Sharing BIBBs ................................................................................................................. 77 A.2 Alarm and Event Management BIBBs ..................................................................................... 79 A.3 Scheduling BIBBs .................................................................................................................... 81 A.4 Trending BIBBs........................................................................................................................ 82 A.5 Device Management BIBBs..................................................................................................... 83 A.6 Virtual Terminal BIBBs............................................................................................................. 88 A.7 Network Management BIBBs................................................................................................... 89

Anhang B BACnet Device - Profile.................................................................................................... 90 B.1 BACnet Operator Workstation (B-OWS).................................................................................. 90 B.2 BACnet Building Controller (B-BC) .......................................................................................... 91 B.3 BACnet Advanced Application Controller (B-AAC).................................................................. 91 B.4 BACnet Application Specific Controller (B-ASC) ..................................................................... 92

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 7

B.5 BACnet Smart Actuator (B-SA)................................................................................................ 92 B.6 BACnet Smart Sensor (B-SS).................................................................................................. 93 B.7 BACnet Gateway (B-GW) ........................................................................................................ 93 B.8 IOB- Profile der Standard BACnet Devices ............................................................................. 94

Anhang C Normung in Europa........................................................................................................... 95 C.1 Unterschiede Europa / USA..................................................................................................... 95 C.3 Einschränkungen bei den europäischen Vor- bzw. Experimentalnormen............................... 95 C.4 Die Struktur der GA-Normung in Europa, Stand 2004 ............................................................ 96 C.4 Grundgedanke des GAEB und Standardleistungsbuchs......................................................... 97

Anhang D Beiblätter zum LV (Beispiele: GA-FL, HW, Netzwerk) ................................................... 102

Anhang E Gebäudeautomation auf der GAEB CD : ....................................................................... 109 E.1 Leistungsbereich 070 - GAEB - XML Version ....................................................................... 109 E.2 Beispiele aus Texten des STLB-Bau 070.............................................................................. 115 E.3 Freie Textbeispiele für Standardbeschreibungen.................................................................. 121 E.4 Freie Textbeispiele für spezielle BACnet Einrichtungen........................................................ 123

Anhang F BACnet Checkliste für interoperable Gebäudeautomation............................................. 124

Anhang G Web-Adressen zur GAEB- Schnittstelle: ........................................................................ 129 Ein getrenntes Dokument "Begriffe und Definitionen für den Leitfaden" erklärt die hier verwendeten Fachbegriffe.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 8

Anmerkung zum Vorwort für die vorliegende deutsche Fassung (zweite Auflage) Für die BACnet Version 1, Revision 4 (2004) wurden weitere Objekttypen und Dienste entwickelt, deren BIBBs und Ausschreibungsrelevante Merkmale nach Übernahme als ANSI/ASHRAE Standard in diesen Leitfasen eingearbeitet werden. Zu dieser BACnet-Ausgabe 2004 gibt es inzwischen weitere Ergänzungen und Korrekturen, die kostenlos auf der ASHRAE Website ( http://www.ashrae.org/publications/detail/15126(Originalfassung): Addendum to Standard 135-2004 Addendum a Revise Life Safety Point and Life Safety Zone object types to modify their behavior when placed out of service, p. 1; Add a new entry to History of Revisions, p.598 Addendum d 135-2004d-1. Add a new Structured View object type, p. 1. 135-2004d-2. Allow acknowledgement of unseen TO-OFFNORMAL event notifications, p. 7. 135-2004d-3. Relax the Private Transfer and Text Message BIBB requirements, p.8. 135-2004d-4. Exclude LIFE_SAFETY and BUFFER_READY notifications from the Alarm Notifications BIBBs, p. 9. 135-2004d-5. Establish the minimum requirements for a BACnet device with an application layer, p. 11. 135-2004d-6. Remove the requirement for the DM-DOB-A BIBB from the B-OWS and B-BC device profiles, p. 13. 135-2004d-7. Relax mandated values for APDU timeouts and retries when configurable, and change default values, p. 14. 135-2004d-8. Fix EventCount handling error in MS/TP Master Node State Machine, p. 15. 135-2004d-9. Permit routers to use a local network number in Device_Address_Binding, p. 17. 135-2004d-10. Identify conditionally writable properties, p.18. 135-2004d-11. Specify Error returns for the AcknowledgeAlarm service, p.19.) Addendum to Standard 135.1-2003 Addendum a 135.1a-1. Add Partial Day Scheduling to the Schedule object, p. 1; 135.1a-2. Enable reporting of proprietary events by the Event Enrollment object, p. 4; 135.1a-3. Allow detailed error reporting when all ReadPropertyMultiple accesses fail, p. 5; 135.1a-4. Remove the Recipient property from the Event Enrollment object, p. 7; 135.1a-5. MS/TP slave proxy tests, p. 9; 135.1a-6 . Add a new silenced mode to the DeviceCommunicationControl service, p. 14; 135.1a-7. Addition of tests for Data Sharing BIBBs, p. 17; 135.1a-8. Specify the behavior of a BACnetARRAY when its size is changed, p. 20; 135.1a-9. Clarifying the behavior of a BACnet router when it receives an unknown network message type, p. 28; 135.1a-10. Testing unsupported service request execution, p. 30; 135.1a-11. Reading entire arrays, p. 32; 135.1a-12. Update negative tests, p. 33.) Eine aktualisierte Fassung des Leitfadens wird bei Bedarf von der BIG-EU im Internet zum Download bereitgestellt, Bitte prüfen Sie regelmässig die Neuerungen auf dieser Website: [email protected]

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 9

0 Zweck dieses Handbuches Dieses Handbuch konzentriert sich auf die kommunikative Verbindung und Interoperabilität von Einrichtungen und Systemen der Gebäudeautomation mittels BACnet®. Es ist für Planer und Betreiber der technischen Gebäudeausrüstung erstellt worden. Es soll die konsistente Anwendung des Kommunikationsprotokolls BACnet für Gebäudeautomationssysteme ermöglichen – bei Neubau und bei Nachrüstungen. Dieses Handbuch unterstützt das Ziel von Bauherrn, unter Wettbewerbsaspekten kosteneffektive und maximal praktikable Gebäudeautomations-Lösungen einzukaufen. Voraussetzung ist die Verwendung eines einheitlichen Kommunikationsprotokolls als Fundament für nicht proprietäre zukünftige Erweiterungen und Ausbauten – unabhängig von Zeitpunkt, Ort und Anzahl. Hierfür müssen alle Einzelprojekte konform mit der BACnet Norm DIN EN ISO 16484-5 geplant und durchgeführt werden. Weiterhin ist ein für eine evtl. Systemintegration Verantwortlicher festzulegen. Dieses Handbuch bietet praktische Empfehlungen für die Vorgehensweise in einem Projekt, es gibt jedoch keine Informationen über die Planung und Ausführung der MSR-Technik für Heizungs-, Lüftungs- und Klimaanlagen sowie für andere projektspezifische Funktionalitäten. Für detaillierte Informationen über Messwertgeber, Stellgeräte, System-Hardware und Verkabelung wird auf die DIN EN ISO 16484-2 Systeme der Gebäudeautomation – Hardware verwiesen. Für detaillierte Beschreibung von Software und Dienstleistungen wird auf die DIN EN ISO 16484-3 Systeme der Gebäudeautomation – Funktionen verwiesen (Ende 2005). Für die Umsetzung der Planung in ein Leistungsverzeichnis wird auf das GAEB STLB-Bau 070 Gebäudeautomation verwiesen (jeweils aktuelle Fassung). (GAEB – Gemeinsamer Ausschuss für Elektronik im Bauwesen, Standardleistungsbuch für das Bauwesen – Dynamische Baudaten, Leistungsbereich 070) Für den nordamerikanischen Markt wird auf die ASHRAE-Guideline 13P „Guideline to Specifying DDC Systems“ verwiesen. 1 BACnet Systemstruktur und Begriffe

1.1 Allgemeines BACS, BACnet - GA-System, GA-Netzwerk Die Abkürzung GA-System (en: BACS) für Gebäudeautomationssystem, steht für ein Netzwerk von mikroprozessorbasierten Einrichtungen, ein GA-Netzwerk (en: Building Automation and Control Network). In diesem Handbuch (und für Leistungsverzeichnisse) wird daher an einigen Stellen „GA-Netzwerk“ anstatt „BACnet“ verwendet. Für Europa wurde der Beschluss gefasst, die Weltnorm EN ISO 16484-5 (oder ANSI/ASHRAE BACnet Standard) selbst nicht in die Nationalsprachen zu übersetzen, da diese Norm eher für Systementwickler vorgesehen ist und diese die Originalsprache bevorzugen. Dieses Handbuch vermittelt dem Planer Informationen in deutscher Sprache (soweit sinnvoll), um interoperable GA-Systeme ausschreiben zu können. Ein getrenntes Dokument "Begriffe und Definitionen für den Leitfaden" erklärt die hier verwendeten Fachbegriffe auf Deutsch, dort werden auch in Originalsprache die wichtigsten BACnet und Kommunikationsbegriffe erläutert.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 10

In Kapitel 1.3 werden dem Leser die hintergründe einiger Begriffe und deren Übersetzung erläutert. In Kapitel 1.4 werden die verwendeten Begriffe und Definitionen aus der DIN EN ISO 16484-2 dargestellt. Kapitel 4.2 enthält die BACnet Kommunikationsobjekte mit Erläuterung und Referenz zur VDI 3814-1 in deutscher Sprache. Damit werden einheitliche Begriffe für die BACnet Objekte und Dienste festgelegt und eine Eindeutigkeit für Ausschreibung, Ausführung und Betrieb der Gebäudeautomation mit BACnet geschaffen. In einem getrennten Dokument für den VDI – BIG-EU Planerkurs sind alle deutschen Begriffe sowie Abkürzungen der Gebäudeautomation abgeleitet aus DIN EN ISO 16484-2 und aus der Normungsarbeit bei ISO und CEN dargestellt.

1.2 Das BACnet Modell der Gebäudeautomation

Gemeinsames Kommunikat ionsprotokoll

Service Messages (APDUs)

Applic. Obj.

Applic. Obj. Applic. Obj.

Applic. Obj.

BACnetAACAutomationsgerät

BACnetOWSBedienstation /-gerätBACnetMS Manage-ment-/ Server Station

BACS network

FF

FF

BACnetASCController

BACnetAS / BC Automationsstation

Lokale Automations Station

Feldgeräte Feldgeräte Feldgeräte Feldgeräte

Obj.

BACnetSFD

Legende:Applic. GA Anwendungsprogramme (Applications)APDUs Daten-Telegramme (Application protocol data units)BACS network GA- Netzwerk (BACnet - Building automation and control network)BACnetBAS/BC Automationsstation (BACnet building automation station / building controller)BACnetAAC Automationsgerät (BACnet Advanced application controller)BACnetASC Anwendungsspezifische Geräte (BACnet application specific controller)BACnetOWS Bedienstation/-gerät (BACnet operator work station)BACnetMS Management/Server Station (BACnet management station) BACnetSFD Vernetzbare Sensoren / Aktoren (BACnet smart field device)BACS GA-System (Building automation and control system)F Nachrichtenfilter (Filtering function) Obj. GA- Kommunikations-Objekte (BACnet objects)

Bild 1-1 – ISO BACnet und seine Device-Typen im Modell der Gebäudeautomation (HAK)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 11

1.3 Hinweise zur deutschen Übersetzung Die deutsche Begriffsfindung auf dem dynamischen Gebiet der Kommunikation für Gebäudeautomation ist noch nicht abgeschlossen. In diesem Handbuch werden daher einige Begriffe aus der englischen Originalfassung verwendet. Einige wurden bisher eher jargonartig übersetzt und waren zu berichtigen. Das deutsche Wort soll kurz und prägnant sein, darf nicht im Widerspruch zur bisherigen Branchen-Nomenklatur stehen und es muss konform mit der Weltnorm DIN EN ISO 16484 sowie mit VOB/C und STLB-Bau 070 sein. Es folgt in Kapitel 1.3 und 1.4 eine Auswahl der wichtigsten Begriffe für dieses Dokument und für BACnet-Systeme generell. Der Zweck ist Rechtsverbindlichkeit von Ausschreibungen und Angeboten. Legende (nach ISO 639): „en“ = englisch, „de“ = deutsch, Die Begriffe der "Originalsprache" sind aus der BACnet-Norm.

Originalsprache (Sortierkriterium)

Deutsch (zur Diskussion)

Anmerkung

alarm and event management - AE

Alarm- und Ereignisverarbeitung

Kontext: Interoperabilitätsbereich

averaging object - AVG Mittelwert-Objekt Auch wenn im Original die Verlaufsform "...ing" festgelegt wurde, die Übersetzung soll wie bei "Analogwert" auf "...wert" enden. Branchenüblich ist "Mittelwert" und nicht "Durchschnitt" für engl.: average.

BACnet GA-Netzwerk Wenn nicht als Wortmarke einzusetzen.

BACnet Interoperability Building Blocks (BIBBs)

BACnet-Interoperabilitätsbausteine

BIBBs, Bestandteil der PICS; singular: BIBB. Akronyme zur Feststellung der Interoperabilität.

calendar object - CAL Betriebskalender-Objekt Zur Unterscheidung vom "Normalkalender", der alle Tage des Jahres umfasst.

command object - CMD Gruppenauftrags-Objekt Der Begriff "Befehl" wäre hier nicht richtig, denn einen "Befehl" erteilt das Ausgabe-Objekt direkt an Relais, Triacs, Schaltschütze oder Stellgeräte, die sich nicht verweigern können (sie schalten bedingungslos), was bei übergeordneten "Aufträgen" an eine andere Instanz so nicht zutrifft. Zur Unterscheidung von "Befehlen" aus der ZLT-Zeit wurde der Begriff "Auftrag" gewählt. Mit einem "Gruppenauftrag" sollen Befehle von unterschiedlichen Instanzen (Ausgabe-Objekten) "gleichzeitig" ausgeführt werden. Siehe auch "Relinquish Command - Auftrags-Zurücknahme“.

data sharing - DS Gemeinsame Datennutzung

Kontext: Interoperabilitätsbereich, man spricht von gemeinsamen (shared) Datenpunkten und gemeinsamen, kommunikativen E/A-Funktionen.

device device type

Device Device-Typ

Die Begriffe "Gerät", "Station", "Hardware", "Knoten" und "Einrichtung" sind immer nur in einer

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 12

Originalsprache (Sortierkriterium)

Deutsch (zur Diskussion)

Anmerkung

bestimmten Wortverbindung richtig, daher wurde "Device" und "Device-Typ" im Deutschen eingeführt, auch um Verwirrungen zu meiden, denn „Device“ für BACnet-Einrichtungen hat sich von Beginn an etabliert. Es kann (selten) auch vorkommen, dass in einer physikalischen Einrichtung mehrere "BACnet-Devices" implementiert werden (z. B. Gateway) und dass ein "Device" nur virtuell (als Software) vorhanden ist.

device and network management - DM

Device- und Netzwerk-Management, Systemverwaltung

Kontext: Interoperabilitätsbereich; DIN EN ISO 16484-3 und -5; es macht Sinn, ggf. zwischen Device- und Netzwerkmanagement zu differenzieren (DM / NM)

device object – DEV Device-Objekt Nach DIN EN ISO 16484-2 auch "Hardware-Objekt"; siehe "device".

event enrollment object - EE

Ereigniskategorie-Objekt "Enrollment" steht für Anmelden und Einschreiben (Abonnieren von Ereignis-Meldungen) im Kontext von "Ereignis-/Alarmbehandlung" nach den vorgegebenen Ereigniskategorien.

group object - GRP Gruppeneingabe-Objekt Abfrage einer Gruppe von Informationen, die von Properties aus mehreren Objekten stammen. Verwechselbar mit der "Gruppenadresse" bei KNX/EIB.

Interoperability area – IA Interoperabilitätsbereich – IOB

Der Autor fand kein sinnbringendes anderes deutsches Wort. Operabel bedeutet "so beschaffen, dass damit gearbeitet, operiert werden kann". Die Vorsilbe "inter" stammt aus dem Lateinischen und bedeutet soviel wie "zwischen" (sie kennzeichnet eine Wechselbeziehung zwischen zwei oder mehreren gleichartigen Dingen, die entweder besteht oder sich vollzieht. Auch: "zwischen", "unter", "inmitten". Vgl. Duden-Wörterbuch). Interoperable Daten sind also Daten aus potenziell unterschiedlichen Quellen, zwischen denen ("inter") eine Beziehung in der Weise besteht, dass mit ihnen gemeinsam gearbeitet ("operiert") werden kann. An das Akronym "IOB" werden wir uns gewöhnen (müssen).

Notification class object - NC

Meldungsklassen-Objekt "Notification" = "Meldung", "Benachrichtigung", "class" steht für "Zugehörigkeit".

operator workstation - OWS

Operator-Workstation Bedienstation

Der (engl.) Begriff steht für Bedien- und/oder Managementeinrichtung. Im Deutschen wird er verwendet, wenn keine Unterscheidung nötig oder möglich ist, das Akronym OWS ist noch unüblich. Im Jargon wird diese oft auch „GLT“ genannt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 13

Originalsprache (Sortierkriterium)

Deutsch (zur Diskussion)

Anmerkung

property Property Objekt-Property

Weder "Eigenschaft" (Verhalten), "Merkmal" (Kennzeichen) noch "Charakteristik" trifft den Kontext in den möglichen Wortverbindungen richtig, es sind die zum Objekt gehörenden Informationen, daher "Objekt-Property" oder nur "Property". Im Englischen steht "property" auch für Besitztum, Requisit. Properties von Objekten sind Namen, Kennzeichen, Attribute, Parameter, Funktionen, Werte, Zustandsbezeichnungen, Status etc.

Protocol Implementation Conformance Statement (PICS)

PICS Protokoll-Umsetzungsbestätigung (Herstellererklärung)

Teil der Unterlagen des Bieters bzw. Auftragnehmers für jede im System eingesetzte BACnet-Einrichtung. (Nach DIN EN ISO 16484-5).

Relinquish Command Auftrags-Zurücknahme (relinquish = engl.: verzichten, loslassen, aufgeben;siehe auch "Gruppenauftrag".

Scheduling Zeitplan / Zeitprogramm Kontext: Interoperabilitätsbereich.

standard object type Genormter Objekttyp Kontext Kommunikation; die offizielle Übersetzung von "type" ist zwar "Art" (Sorte), Objekttyp war jedoch schon zu breit eingeführt; deutsch: Typ = Person, Charakter; Technische Ausnahmen sind: Typenschild, Typenprüfung, Typklasse, nun auch Objekttyp und Device-Typ; (engl.) „Standard" wird oft falsch mit "Standard" übersetzt, richtig wäre: Norm, genormt.

state Zustand Betriebs- oder Alarmzustand; siehe Begriffe u. Definitionen der GA-Norm. Vgl. Status. Beispiele: aus, ein, offen, geschlossen, Störung.

status Status Relative Bedeutung eines Zustands; siehe Begriffe u. Definitionen der GA-Norm. Vgl. Zustand. Beispiele: ausser Betrieb, online, Aderbruch.

trend log object - TLOG Trend-Aufzeichnungs-Objekt

Der (engl.) Begriff "trend log" steht für "Tendenzaufzeichnung" zur Darstellung im Zeitreihendiagramm. "Trend" ist in der Branche ein geläufiger Begriff. Dieser Objekttyp kann auch für Einträge in die History-Datenbank (für Management-Funktionen) genutzt werden.

trending - T Trend-Aufzeichnung (1) Kontext: Interoperabilitätsbereich. Speicherung von Zeit/Wert-Paaren beginnend vom aktuellen Zeitpunkt mit Werten der kürzeren Vergangenheit.

trendlog Trend-Aufzeichnung (2) und Darstellung

Trend-Diagramm; auch: Zeitreihendiagramm.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 14

Besonderheiten zum Begriff "Device" In vereinfachenden Wörterbüchern finden wir als Übersetzung "das Gerät". Dieser Begriff ist jedoch fest

definiert, insbesondere in Bezug auf Industrieprodukte und in Gesetzen ("Gerätesicherheitsgesetz", "EMV-

Gesetz"). Gerät ist umgangssprachlich als Synonym für ein technisches Gebilde gebräuchlich, auch

Apparat oder Maschine genannt, zum Beispiel ein Radio- oder Fernsehgerät.

Gatewayfunktionen können in einem "Gerät", einer "Station" oder einer "Software" sein. In einem Gateway

können viele virtuelle "BACnet-Devices" (Geräte?) programmiert sein, auch in einer grossen

Automationsstation und ganz bestimmt in einer Managementeinrichtung. Wie viele "(BACnet-)Geräte" sind

nun als "BACnet-Devices" in einem PC mit mehreren Netzwerk-Schnittstellen? Daher ist es eindeutiger,

den Begriff "Device" im Kontext "BACnet-Device" stehen zu lassen.

1.4 Verwendete Begriffe und Definitionen nach DIN EN ISO 16484-2

1.4.1 Hinweis Es wird auf die Begriffe und Definitionen zum BACnet-Leitfaden der B.I.G. EU, auf das Glossar der

Normenserie DIN EN ISO 16484 (siehe Anmerkung zur Übersetzung im Vorwort, Seite 4), auf die

Richtlinienreihe VDI 3814 ("VDI 3814-Standard"), und auf die Terminologie-Fachbroschüren der GA-

Hersteller verwiesen. Rechtlich verbindlich sind jedoch nur die Begriffe der Weltnorm DIN EN ISO 16484.

Die Gebäudeautomation hat derzeit bereits weit über 450 fachspezifische Begriffe. Die Begriffe der

allgemeinen MSR-Technik sind im IEV (International Electrotechnical Vocabulary) IEC 60050-351 definiert.

1.4.2 Begriffe für diesen Leitfaden Die wichtigsten der verwendeten Begriffe, Definitionen und Übersetzungen befinden sich im getrennten

Anhang zum BACnet-Leitfaden, zu beziehen per Download von der Website der BIG-EU.

Ebenso gehört das Glossar zu den Unterlagen des BIG-EU- BACnet-Kurses im VDI – IWB

(Wissensforum), Kurs Nr. 42-25-xx: "Gebäudeautomation mit BACnet".

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 15

1.5 Hinweise zu den Kommunikationsfunktionen

1.5.1 E/A-Funktionen A) Allgemeines Eingabe- und Ausgabefunktionen nach DIN EN ISO 16484-3 enthalten alle erforderlichen Softwareprogramme und Leistungen der technischen Bearbeitung wie Inbetriebnahme, Dokumentation und Betreiber-Einweisung zur Erfassung von Zuständen und Werten der Messwert- und Kontakteingänge und zur Ausgabe von Schalt- und Stellbefehlen sowie für gemeinsame, kommunikative Datenpunkte. Die Informationen der E/A-Funktionen stehen für weitere Verarbeitungen durch alle anderen GA-Funktionen zur Verfügung. Zu den Parametern der E/A-Funktionen gehören z. B. Datenpunktadressen, Kennlinien und Bereiche von Sensoren, SI-Einheiten, Zustands- und zugehörige Statusbeschreibungen, Text- und Parameterzuweisungen, jedoch nicht das Kommunikationsprotokoll bei gemeinsamen Datenpunkten. B) Eingabe- und Ausgabefunktionen für gemeinsame, kommunikative Datenpunkte E/A-Funktionen für gemeinsame, kommunikative Datenpunkte betreffen die dem Benutzer zugänglichen virtuellen Datenpunkte bei vernetzten Einrichtungen unterschiedlicher Systemerrichter oder mit Fremdgeräten bei Systemintegrationsprojekten. Die Datenpunkte haben eine eindeutige Datenpunkt- oder Benutzeradresse zur Identifizierung. Diese E/A-Funktionen für gemeinsame, kommunikative Datenpunkte ermöglichen die Festlegung der Zuordnung von Datenpunkten und Funktionen zu unterschiedlichen Fremdsystemen oder SBA bei Kommunikation z. B. über eine Datenschnittstelleneinheit oder ein Netzwerk. Gemeinsame, kommunikative Datenpunkte können das Ergebnis einer Berechnung und/oder einer logischen Verknüpfung darstellen, welches zwischen Systemen übertragen werden muss, z. B. Verbrauch eines Heizkessels oder einer Kälteanlage. Es ist eindeutig festzulegen, wo eine Peer-to-Peer-Funktionalität zwischen Einrichtungen unterschiedlicher Errichter erforderlich ist. Der Informationsumfang für die Interoperabilität von gemeinsamen Datenpunkten ist konform zum gewählten Kommunikationsprotokoll festzulegen, siehe ISO 16484-5.

1.5.2 Managementfunktionen A) Allgemeines Managementfunktionen werden genutzt, um Daten für Speicherung, Auswertung und Anzeige durch Anwendungsprogramme für Statistik und Datenanalyse zur Verfügung zu stellen. Die ausgewählten Informationen können in Dateien und Datenbanken zur Verarbeitung gespeichert werden. Management-Kommunikationsfunktionen werden genutzt, um Datenpunkt-Informationen aus E/A-Funktionen und Verarbeitungsfunktionen auszuwählen und auf Managementeinrichtungen verfügbar zu machen. Sie dienen auch dazu, um gemeinsame Datenpunktfunktionen für interoperable Systemkopplungen auszuwählen und festzulegen. B) Management-Kommunikationsfunktionen Management-Kommunikationsfunktionen betreffen Informationen von Datenpunkten und Kommunikationsobjekten, die zwischen E/A- bzw. Verarbeitungsfunktionen und Managementfunktionen übertragen werden. Bei interoperablen, heterogenen Systemen werden diese Funktionen zweimal erforderlich, sowohl für das Serversystem als auch für das Clientsystem. Die Arten von Kommunikationsobjekten, die von und zu den Managementfunktionen übertragen werden, unterscheiden sich im Hinblick auf die Komplexität der Daten. Sie werden getrennt in zwei Spalten des Abschnitts sieben der GA-FL aufgeführt. Es erfolgt ein Eintrag je Funktion für beide Kommunikationsrichtungen. Der Informationsumfang für die Interoperabilität bei gemeinsamen Datenpunkten für Managementfunktionen ist konform zum gewählten Kommunikationsprotokoll festzulegen, siehe Protocol

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 16

Implementation Conformance Statement (PICS) und BACnet Interoperability Building Blocks (BIBBs) in ISO 16484-5. Wenn erforderlich, dürfen in der GA-FL Client-Funktionen mit „A“ und Server-Funktionen mit „B“ gekennzeichnet werden. ANMERKUNG Siehe EN ISO 16484-5 für evtl. Änderungen. C) Eingabe-/Ausgabe Kommunikationsobjekt Die Kommunikationsfunktion für Ein-/Ausgabe Objekttypen gilt für Daten, die an oder von den Managementfunktionen übertragen werden und als einfach gelten, z. B. E/A-Datenpunktinformationen mit Zustandsinformationen, Werten und weiteren bei den E/A-Funktionen beschriebenen Attributen und Eigenschaften, wie in 5.5.2 beschrieben. Für Interoperabilität heterogener Systeme bezogen auf Management- und Bedienfunktionalität sind die gemeinsamen analogen und binären Datenpunkte/Kommunikationsobjekte nach ISO 16484-5 in der GA-FL festzulegen. D) Komplexe Kommunikationsobjekte Die Kommunikationsfunktion für komplexe Objekttypen gilt für Daten, die an die oder von den Managementfunktionen übertragen werden. Für Interoperabilität heterogener Systeme sind die Kommunikationsobjekte beschrieben in ISO 16484-5, in der GA-FL und in weiteren Dokumenten festzulegen. Ein gemeinsamer Datenpunkt oder eine vernetzte Einrichtung/Station kann sich auf mehrere komplexe Objekttypen beziehen, deren Anwendung in der Kommentarspalte der GA-FL vermerkt werden sollte, z. B.:

Die Management-Kommunikationsfunktion für komplexe Objekttypen gilt für Daten oder Informationen, die an oder von den Managementfunktionen bzw. Bedienfunktionen an oder von Fremdsystemen übertragen werden. Die GA-Weltnorm Teil 3 fordert, dass für Interoperabilität heterogener Systeme die Kommunikationsobjekte, beschrieben im BACnet-Standard, in der GA FL und in weiteren Dokumenten festzulegen sind. In diesem Buch wird eine Empfehlung für die Zuordnung gegeben. Wir unterscheiden für diesen Zweck die komplexen Objekttypen in drei Varianten: in GA-Funktionen mit Zuordnung zu Datenpunkten für jedes Projekt, in solche für geplante, heterogene Projekte und in übergeordnete Systemfunktionen. Eine Beschreibung dieser Objekttypen ist in der Übersicht, Kapitel 4, Tabelle 4-01 gegeben. Die Zahlen in Klammern bei der folgenden Aufstellung bedeuten die zugeordnete Spaltennummer der GA-FL. Folgende (komplexe) Objekttypen (7.2) lassen sich zu eigenständigen (virtuellen) Datenpunkten zuordnen: - Gruppenauftrags-Objekt (engl.: command object), als virtueller DP, z. B. Datenpunkt

"Gesamtanlage", "Raum-Betriebsart", ausgelöst von z. B. Optimierungsfunktionen (6.3 bis 6.13); - Gefahrenmelder-Objekt (engl.: life safety point object) als komplexe physikalische

Eingabefunktion; - Sicherheitsbereichs-Objekt (engl.: life safety zone object), als virtueller DP, z. B. für eine

Zusammenfassung mehrerer Melder in einem definierten Gefahrenbereich in Verbindung mit der Funktion Meldungsbearbeitung (3.6), bei heterogenen Systemen insbesondere für Management- und Bedienfunktionen (7.3/7.4 und 8.2), (oft wird dieses Objekt mit einer "Meldelinie" verglichen).

Nur unter bestimmten Bedingungen, wie bei geplanten heterogenen Systemen, lassen sich die folgenden (komplexen) Objekttypen (7.2) eigenständigen (virtuellen) Datenpunkten zuordnen:

- Device-Objekt; (engl.: device object; nach DIN EN ISO 16484-2: Hardwareobjekt); als System-Grundparameter (systeminterne Funktion) keine Automationsfunktion für die GA-FL; es ist ein zusätzlicher virtueller Datenpunkt nach 7.2 bei heterogenen Systemen; für eine

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 17

Lebenszeichenüberwachung (Watchdog) sind eigene gemeinsame, kommunikative Datenpunkte einzurichten.

- Ereignis-Aufzeichnung (engl.: event log), wird bei heterogenen Systemen als virtueller DP angegeben, ansonsten ist die Kommunikation z. B. in folgenden Funktionen enthalten: Ereignis-Langzeitspeicherung (7.3), Historisierung in Datenbank (7.4);

- Globales Gruppeneingabe-Objekt (engl.: global group object), wird bei heterogenen Systemen als virtueller DP angegeben, ansonsten ist die Kommunikation z. B. in folgenden Funktionen enthalten: Meldungsbearbeitung (3.6) (Sammelmeldung), Rechenfunktionen (6.1, 6.2). Managementfunktionen (7.3, 7.4) und Bedienfunktion (8.2);

- - Gruppeneingabe-Objekt (engl.: group object), siehe "Globales Gruppeneingabe-Objekt"; - Reglerobjekt (engl.: loop object), wird bei heterogenen Systemen als virtueller DP unter 7.2

angegeben, ansonsten ist die Kommunikation z. B. durch folgende Funktionen spezifiziert: Managementfunktion 7.3, 7.4, Bedienfunktion "dynamische Einblendung" (8.2) und die Reglerfunktionen (5.1-5.8);

- Programm-Objekt (engl.: program object), wird bei heterogenen Systemen als virtueller DP angegeben, das Programm muss zusätzlich als getrennte Position beschrieben werden;

- Zeitplan-Objekt (engl.: schedule object), wird bei heterogenen Systemen als virtueller DP angegeben, ansonsten ist die Kommunikation in der GA-Funktion "Zeitabhängiges Schalten" (6.4) enthalten, wird auch für die GA-Funktionen 6.5 bis 6.7 und ggf. 6.12/6.13 benötigt;

- Ereignis-Aufzeichnungs-Objekt (engl.: event log object), wird bei heterogenen Systemen als virtueller DP angegeben, ansonsten ist die Kommunikation z. B. in folgenden Funktionen enthalten: Ereignis-Langzeitspeicherung (7.3), Historisierung in Datenbank (7.4);

- Trend-Aufzeichnungs-Objekt (engl.: trend log object), wird bei heterogenen Systemen als virtueller DP angegeben, ansonsten ist die Kommunikation z. B. in folgenden Funktionen enthalten: Ereignis-Langzeitspeicherung (7.3), Historisierung in Datenbank (7.4);

- Mehrfachtrend-Aufzeichnungs-Objekt (engl.: trend log multiple object), siehe Trend-Aufzeichnungs-Objekt.

Für die folgenden komplexen Objekttypen, die interoperable Systemparameter spezifizieren, gibt es keine direkte Zuordnung zu den GA-Management-Funktionen für die GA-FL:

- Betriebskalender-Objekt (engl.: calendar object), es sind Systemparameter in Verbindung mit dem Zeitplan-Objekt, die Dienstleistung der Ersteingabe ist in der GA-Funktion "Zeitabhängiges Schalten" (6.4) enthalten;

- Ereigniskategorie-Objekt (engl.: event enrollment object), als System-Grundparameter oder systeminterne Funktion ist keine Automationsfunktion für die GA-FL;

- Dateiobjekt (engl.: file object), als System-Grundparameter oder systeminterne Funktion ist keine Automationsfunktion für die GA-FL; muss bei heterogenen Systemen als getrennte Position beschrieben werden;

- Meldungsklassen-Objekt (engl.: notification class), als System-Grundparameter oder systeminterne Funktion ist keine Automationsfunktion für die GA-FL;

Für die Zuordnung der Objekttypen zum VDI-3814-Standard siehe auch Tabelle 4-01.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 18

1.6 Kommunikationspfade in GA-Systemen nach DIN EN ISO 16484-2

AnwendungsspezifischeSteuer- und Regeleinheit

(ASR)

Jalousien / Sonnenschutz

Licht / Dimmen

Verbindungen innerhalb der funktionalen Ebenen

Verbindungen zwischen den funktionalen Ebenen

Aut

omat

ion

Bedienstation /Bedieneinheit

Programmier-einheit

Bedienstation / Bediengerät

Datenschnitt- stelleneinheit

Programmier- einheit

Man

agem

ent

Netzwerk

Datenverarbeitungs- einrichtung / Serverstation

Lokale Vorrang-Bedieneinheiten

System für besondere

Anwendungen

System für besondere

Anwendungen

Datenschnitt-stelleneinheit

System fürbesondere

Anwendungen

Feld

Netzwerk

Controller / Automationsstation / ASR

M

Netzwerk

Net

zwer

k

Raum-bediengerät

Kommunikationseinheit / Controller /

ASR

Datenschnitt-stelleneinheit

Bediengerät

M MMM

Bild 2: EN ISO 16484-2 Mögliche Verbindungen in GA-Systemen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 19

2 Spezifikation interoperabler BACnet-Systeme

2.1 Ziel von BACnet BACnet, das Protokoll für die offene Kommunikation in der Gebäudeautomation, wurde von der ASHRAE American Society of Heating, Refrigerating and Air-Conditioning Engineers als Richtlinie entworfen, um einen einheitlichen und einzigen firmenneutralen Standard für die Datenkommunikation in und mit Systemen der Gebäudeautomation bereitzustellen. Die „Schwesterorganisation“ VDI-TGA (Verein Deutscher Ingenieure – Gesellschaft Technische Gebäudeausrüstung) unterstützt dieses Projekt durch Beteiligung an der Normung und Schulung. Das Ziel dieser Richtlinienarbeit war und ist „Interoperabilität“. Auch wenn Interoperabilität meistens in Verbindung mit Einrichtungen unterschiedlicher Hersteller gewünscht wird, ist es prinzipiell auch denkbar, Interoperabilität bei Einrichtungen eines einzelnen Herstellers zu betrachten. Beispielsweise wenn mehrere Systemgenerationen eines einzelnen Herstellers in einem GA-System zusammenarbeiten. BACnet ermöglicht die Interoperabilität von Systemen/Einrichtungen verschiedener Hersteller, setzt aber keineswegs voraus, dass in einem Gebäude Produkte unterschiedlicher Hersteller vorhanden sein müssen. BACnet stellt, passend zu den vielfältigen Anforderungen an eine Gebäudeautomation, eine Anzahl an Regeln bereit, um Interoperabilität zu erreichen. Im Sinne der Wirtschaftlichkeit soll eine sinnvolle Selektion der optionalen Regeln für die einzelnen Funktionen der TGA durchgeführt werden, wofür dieses Handbuch Hilfestellung gibt.

2.2 Festlegen der Anforderungen an interoperable Systeme 1. Festlegung der benötigten Datenpunkte und GA-Funktionen aus den Automationsschemata und

Steuerungsablaufplänen bzw. Automationsbeschreibungen für die Funktion der zu automatisierenden Anlagen. Das allgemein anerkannte Hilfsmittel hierfür ist die Funktionsliste nach DIN ISO 16484-3 (früher VDI 3814-2) (Beispiele in VDI 3814-4).

2. Festlegung der benötigten GA-Funktionen für die Bedienung und Beobachtung der Anlagen. 3. Festlegung der benötigten GA-Funktionen für die Managementaufgaben. 4. Festlegung der IOBs (Interoperabilitätsbereiche) (Kapitel 3). 5. Festlegung der Funktionen, welche die jeweiligen Teil-Systeme unter Berücksichtigung der

Merkmale für die IOBs (Interoperabilitätsbereiche) erfüllen sollen. 6. Festlegung der vorgesehenen Netzwerktechnik (LAN oder WAN). 7. Festlegung der Netzwerktrassen mit Bestimmung der Entfernung zwischen den Einrichtungen gem.

Muster GAEB Beiblatt 070-10 8. Festlegung, dass auf den Netzwerken der TGA das BACnet-Protokoll lauffähig ist, 9. Festlegung dass die entsprechenden Einrichtungen die BACnet-Profile aufweisen, welche gem.

Anhang B dieses Dokuments gefordert sind. 10. Festlegung der zusätzlich erforderlichen BACnet Merkmale, die aus den Empfehlungen in diesem

Dokument hervorgehen. 11. Ermitteln der erforderlichen Massen für das Leistungsverzeichnis. 12. Aufstellen der Leistungsbeschreibung

Für öffentliche Bauvorhaben wird eine Ausschreibung mit Vergabeunterlagen nach VOB/A §10 verlangt, für private wird diese empfohlen.

13. Für die Leistungsbeschreibung (Texte der LV-Standardbeschreibungen und -Positionen) steht das STLB-Bau 070 mit BACnet zur Verfügung. (GAEB Standardleistungsbuch für das Bauwesen – Dynamische Baudaten, Beuth-Verlag,

www.DIN-Bauportal.dewww.BEUTH.dewww.GAEB.de www.bundesaussschreibungsblatt.de

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 20

3 Interoperabilitätsbereiche – IOB (en: interoperability areas „IAs“)

3.1 Definition Die Definition von IOB stellt die Grundlage dieses Handbuchs dar. Aus Sicht des Planers wird ein BACnet-System mit einer Ansammlung der benötigten GA-Funktionen beschrieben. Dabei ist es nicht notwendig, die dafür zugrunde liegenden BACnet-Funktionen zu kennen. Gefordert ist die Festlegung von Mindestanforderungen in Form von BACnet-Interoperabilitäts-Bausteinen (en: BACnet Interoperability Building Blocks - BIBBs) nach Anhang A. IOB definieren die Funktionalität für einen bestimmten Teilbereich der Anforderungen. Die fünf Interoperabilitätsbereiche sind: IOB 1. Gemeinsame Datennutzung, DS (en: data sharing), 2. Alarm- und Ereignisverarbeitung, AE (en: alarm and event management), 3. Zeitprogramme, SCHED (en: scheduling), 4. Trend-Aufzeichnung, T (en: trending), 5. Device- und Netzwerkmanagement, DM (en: device and network management). Jeder IOB umfasst eine Anzahl an Merkmalen. Jedes Merkmal erfordert wiederum, dass bestimmte Elemente des BACnet-Protokolls in einer bestimmten Einrichtung implementiert sind. Das interoperable Verhalten wird dadurch vorhersagbar. In den „Device profiles“ im Anhang B sind die für den jeweiligen IOB empfohlenen BACnet-Elemente für die jeweilige Art der Einrichtung (device type) aufgeführt. Dieser Teil gibt Planungshinweise, welche für jeden IOB zu beachtet sind. ANMERKUNG: Die erste BACnet Norm (ANSI/ASHRAE 135-1995) hat versucht, die Spezifikation von GA-Systemen mit „Conformance Classes“ und Functional Groups“ durchzuführen. Conformance Classes waren dabei sechs hierarchische Klassen, welche in aufsteigender Komplexität die Anforderungen an Gebäude-Automations-Systeme darstellen. Die jeweils höhere Klasse beinhaltet alle Funktionalitäten der darunter befindlichen Konformitäts-Klassen. Funktionelle Gruppen sind zusätzliche Sammlungen von BACnet-Merkmale, mit dem Zweck bestimmte Aufgaben zu erfüllen. Der Ansatz war, dass man eine Einrichtung einer bestimmten Konformitäts-Klasse zuordnen kann. Mit den funktionellen Gruppen sollten die benötigten Funktionalitäten der BACnet Einrichtung in der Praxis beschrieben werden. Dieses Konzept, obwohl gut gemeint, scheiterte, da die Kombination aus Konformitäts-Klasse und funktioneller Gruppe nicht ausreichten, um die Produkte der realen Welt erschöpfend zu beschreiben. Zudem setzt diese Vorgehensweise ein in den meisten Fällen nicht vorhandenes Wissen über die Details der BACnet Norm bei Planern und Gebäudebetreibern voraus.

3.2 DS - Gemeinsame Datennutzung (en: data sharing)

3.2.1 Allgemeines „Datenaustausch“ (data sharing) ist der Austausch von formalisiert dargestellten Informationen zwischen BACnet-Einrichtungen zur gemeinsamen Nutzung. Dies kann sowohl in eine Richtung oder auch beidseitig geschehen. Die Interoperabilität entsteht durch die Interpretation dieser Daten gem. den Festlegungen im Protokoll. Zweck des Datenaustausches ist das gemeinsame Verwerten von Sensorinformationen oder von abgeleiteten Werten, das Verändern von Sollwerten und anderen Parametern, das Darstellen der Werte in Grafiken und Berichten und die Datenhistorisierung. Wir unterscheiden für ein Leistungsverzeichnis die Kommunikation für Ein-/Ausgabe Funktionen und Mananagementfunktionen – siehe DIN EN ISO 16484-3 GA-Funktionsliste.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 21

3.2.2 GA-Funktionsliste Um ein heterogenes BACnet GA-System korrekt in Bezug auf den Datenaustausch kalkulieren zu können, muss das Leistungsverzeichnis die Menge an Kommunikationsfunktionen, ermittelt aus der GA-Funktionsliste, enthalten – für jedes Teilsystem. Grundlage für diese GA-Funktionsliste ist das jeweilige Automationsschema der Anlage. Nach Eintragung der Feldgeräte entsteht die GA-Datenpunktliste – strukturiert nach der Topologie des Projekts, z. B. nach Informationsschwerpunkten (en: mechanical equipment rooms). Diese Datenpunktliste wird mit den Funktionen nach DIN EN ISO 16484-3 ergänzt, ggf. kann ein Zustandsdiagramm die Steuerung der Anlage verdeutlichen. Die Planung muss jeden analogen und binären/digitalen Datenpunkt mit den darin enthaltenen Informationen (Zustände, Werte), welche über das Netzwerk im Zugriff stehen sollen, festlegen. Dies Erfolgt über die Angabe der Anzahl und Art der Funktionen pro Datenpunkt, ggf. mit Hinweis auf BACnet Objekte und ob als Client oder Server (durch Festlegung der BIBBs).

3.2.3 Darstellung der Informationen Die kommunizierten Datenpunktinformationen als Daten-Elemente in den entsprechenden BACnet- oder Kommunikationsobjekt-Typen werden von den GA-Anwendungsprogrammen gem. DIN EN ISO 16484-3, 5.3, verwendet. Dazu gehören z. B. Programme der Mensch-System-Schnittstelle. Die nachfolgend aufgeführten Anforderungen sind, falls erforderlich, im Leistungsverzeichnis festzulegen. Die Bedienfunktionen sind zusammen mit den dafür erforderlichen Kommunikationsfunktionen dem entsprechenden Teilsystem zuzuordnen, hierzu ist im LV die Forderung durch die Zuordnung der GA-Funktionen Anlagenbild, dynamische Einblendung, Ereignis-Anweisungstext und Nachricht an externe Stelle in der GA-Funktionsliste dokumentiert und mit den entsprechenden LV-Positionen festgelegt. Die Wert-Aktualisierungs-Zeit für dynamische Einblendugen in einer grafischen Darstellung ist für das Bediensystem in der System-Standardbeschreibung unter „Reaktionszeiten im systemeigenen Netzwerk“ festzulegen (Die Zeiten in Sekunden richten sich nach den Anforderungen des Projektes). Alle geforderten binären/digitalen und analogen Werte sind pro grafische Darstellung gleichzeitig und in Echtzeit darzustellen. (Für die Historisierung von Werten siehe die Anmerkungen in Kapitel 3.4). Es ist gefordert, dass alle Datenpunkte in den verbundenen Systemen für die gemeinsame Datennutzung verwendbar sind. Hierzu gehören alle normativen sowie die geforderten optionalen und proprietären Properties der zugehörigen BACnet Objekttypen von jeder Einrichtung im GA-Netzwerk. Die Wert-Aktualisierungs-Zeit für die Langzeit-Datenspeicherung und Historisierung ist festzulegen, wenn nicht das COV/COS Verfahren gefordert ist. Bei zeitdiskreter Speicherung sind schnelle Prozesse, wie Regelungen von Dampf, Druckluft, etc. mit schnellen Intervallen (ca. 1 Sekunde) zu wählen. Für langsame Prozesse, wie der Überwachung von Raumtemperaturen, ist ein Intervall von 30 Sekunden bis 60 Sekunden ausreichend. Bei dem COV/COS (change of value/state reporting) Verfahren senden die Devices den Wert automatisch bei einer Wertveränderung um einen definierten Schwellenwert. Das gewünschte Format von vordefinierten Berichten (Tabellen-Ausdrucken) ist mit den zugeordneten Einzelwerten oder Datensätzen festzulegen. Aus STLB-Bau 070 Bediensoftware Darstellung pro Benutzeradresse auf Ausgabegeräten mit folgenden zusätzlichen Angaben: Datum und Zeit sowie Zustand oder Wert und Einheit mit erläuterndem alphanumerischen Klartext, mit optischer Visualisierung durch Farbumschlag, Blinken oder bewegter Animation auf Sichtgeräten, mit Kennzeichnung Zustand/Wert als aktuell/alt, Grenzwerte mit erläuternden Texten, Unterscheidung von Meldungen nach Kategorien, Kennzeichnung von Stör- und Alarmmeldungen als quittiert/unquittiert, mit quittierbarer akustischer Signalisierung, Alarm in allen Bedienzuständen sichtbar im Sichtgeräte-Vordergrund, …….

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 22

3.2.4 Systemübergreifende Datenpunkte (en: global objects) Einige Datenpunkte repräsentieren in ihren Kommunikationsobjekten systemübergreifend benötigte Informationen. Typische Beispiele dafür sind gemeinsam benutzte Messwerte, wie z. B. die Aussentemperatur oder gemeinsam benutzte binäre Informationen, wie Anlagenbetriebszustände. Ist die Übertragung mittels COV/COS ereignisorientiert gefordert, muss der Schwellenwert für eine neue Wertübertragung festgelegt werden, z. B. 0,1 K. Ansonsten ist die Häufigkeit der Wertübertragung für diese Kommunikationsobjekte festzulegen, z. B. 1 x pro Minute, 1 x pro Stunde, 1 x pro Tag.

3.2.5 Sollwert- und Parameteränderung Ein Bediener mit entsprechender Berechtigung muss in der Lage sein, jeden gewünschten Sollwert der Regelfunktionen oder andere gewünschte Parameter im Netzwerk zu verändern bzw. zu überschreiben. Da mache Automationseinrichtungen vorkonfiguriert, d.h. deren Parameter nicht zugänglich sind, ist es erforderlich festzulegen, welche Sollwerte oder Parameter über das GA-Netzwerk veränderbar sind. - Festlegung der Kommunikations- und Bedienfunktionen bei Datenpunkten mit zugeordneter Regelfunktion. - Festlegung der Kommunikations- und Bedienfunktionen bei Datenpunkten mit zugeordneter Optimierungsfunktion

wie z.B. Zeit- oder Tarifabhängiges Schalten, Höchstlastbegrenzung. - Festlegung, ob und ggf. wie diese Bedienfunktionen in einer grafischen Darstellung vorgesehen sind.

3.2.6 Peer-to-Peer Datenübertragung BACnet ermöglicht den direkten und automatischen Datenaustausch zwischen vernetzten Devices unterschiedlicher Hersteller. Diese Funktion muss in jedem Falle eindeutig und umfassend beschrieben und dokumentiert werden (Funktionsgewährleistung). - Festlegung aller erforderlichen gegenseitigen Daten- und Funktionsabhängigkeiten, sowie Verriegelungen,

gemeinsame Sollwerte und Parameter, Zeitdaten und –parameter, usw., welche über das GA-Netzwerk implementiert werden sollen.

3.3 AE - Alarm- und Ereignisverarbeitung

3.3.1 Allgemeines Der „Datenaustausch“ für Alarm- und Ereignisverarbeitung verwendet spezielle Objekttypen. Deren Besonderheit ist die Reaktion auf ein Ereignis, welche das Eintreten eines vordefinierten Zustands mit spezifizierten Kriterien darstellt. Ein Ereignis kann spezifizierte Aktionen auslösen oder nur registriert werden, z. B. in einem Betriebs- oder Alarm-Protokoll. Ein Ereignis kann auch einen Zustand repräsentieren, welcher einen Alarm auslöst und eine Quittierung durch einen Bediener erfordert. Interoperabilität in diesem Bereich erlaubt die Benachrichtigung über und das Quittieren von Alarmen; die Darstellung von Ereignis- und Alarm-Informationen, die programmierte Reaktion auf Ereignisse im GA-Netzwerk; die Veränderung von Alarm-Grenzen, das Weiterleiten von Ereignis- und Alarm-Informationen, sowie die Langzeitspeicherung oder Historisierung für nachfolgende Auswertungen. BACnet definiert zwei verschiedene Mechanismen für das Erzeugen von Alarmen und Ereignissen. Der erste Mechanismus wird als „objektinternes Melden“ (en: intrinsic reporting) bezeichnet, weil er auf den objekteigenen Properties beruht, die für das Überwachen eines Ereignisses oder Alarms zugrunde liegen. Der andere Mechanismus wird als „regelbasiertes Melden“ (algorithmic change reporting) bezeichnet. Das regelbasierte Melden ist funktional umfassender, da es auf dem zusätzlichen Ereigniskategorieobjekt (en: Event Enrollment object) basiert. Das objektinterne Melden ist vorzuziehen, wenn es die Anforderungen erfüllt.

3.3.2 Darstellung von Ereignis- und Alarm-Informationen Die Art der Darstellung und die Aussagen einer geforderten Alarmzustandinformationen sowie die Art und Weise wie der Bediener über sie informiert werden soll, muss festgelegt werden. - Festlegung der geforderten Überwachungs- und Verriegelungsfunktionen für Alarmereignisse bei jedem

betroffenen Datenpunkt. Dazu gehören Alarmgrenzwerte, Unterdrückungen, Verzögerungen und Verknüpfungen. Für Reaktionszeiten siehe 3.2.3.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 23

- Festlegung der Alarmkategorien, wenn erforderlich. - Festlegung der Alarmverteilung im Gesamtsystem. (Siehe fogenden Anschnitt). - Festlegung der Darstellungsart auf der Bedieneinrichtung/den Bedieneinrichtungen.

3.3.3 Alarm-Quittierung Es ist festzulegen, ob und welche Bedieneraktivitäten gespeichert werden (Systemverwaltung). - Festlegung welches Alarmereignis über das GA-Netzwerk zu quittieren ist, (Funktion Sicherheitssteuerung). - Festlegung welches Alarmereignis in die Ereignis-Langzeitspeicherung für ein separates Alarm-Protokoll

einzutragen ist, (mit Zeitstempel des Auftretens und der Quittierung sowie der Bedienerkennung).

3.3.4 Alarmmeldung/-Bericht Es muss möglich sein, zu jedem Zeitpunkt den Zustand aller definierten Alarm-Datenpunkte festzustellen. Siehe DIN EN ISO 16484-3, Alarm-/Ereignisstatistik. Festlegung von Berichten, die über die in der GA-Weltnorm und im STLB-Bau 070 spezifizierten hinausgehen. - Festlegung von Alarm-Weitermeldungs-Strategien:

– in Abhängigkeit der verwendeten BACnet-Übertragungsart (COV/COS) Meldeart, – in Abhängigkeit des aktuellen Zustands, – in Abhängigkeit der Alarm-Priorität und Meldeklasse, – für bestimmte Empfänger.

Diese Konzepte werden noch ausführlich diskutiert werden.

3.3.5 Grenzwert-Parameter-Einstellung Es muss für jeden Bediener bei entsprechender Berechtigung möglich sein, die Alarmgrenzen der Grenzwertfunktionen bei analogen Datenpunkten im GA-Netzwerk zu verändern. - Festlegung aller erforderlichen Kommunikations- und Bedienfunktionen für feste oder gleitende

Grenzwertüberwachung.

3.3.6 Alarm-Weiterleitung (en: alarm routing) BACnet ermöglicht, Alarminformationen an unterschiedliche Ziele zu senden. Dies kann in Abhängigkeit von der Ereignis-/Alarm-Art, der Alarm-Priorität oder -kategorie und der Nutzungszeiten, wie Wochentag, Tageszeit usw. erfolgen. - Festlegung der Veränderungsmöglichkeit durch den Bediener (falls gefordert) für die Weiterleitung von Alarmen.

Dies beinhaltet das Meldeziel für jede Alarm-Art oder Kategorie, bzw. Priorität, - Festlegung der Art und Weise wie ein Ereignis/Alarm im System behandelt wird, z. B. wenn ausgelöst, wenn

behoben. - Festlegung der Alarm-Weiterleitungsabhängigkeit von Nutzungszeiten ggf. durch Eintrag unter zeitabhängiges

Schalten in der GA-Funktionsliste (falls vom Errichter des Systems einzurichten).

3.4 SCHED - Zeitplan (en: scheduling)

3.4.1 Allgemeines Zeitplan bezeichnet den Datenaustausch in einem heterogenen GA-Netzwerk bezogen auf die Einrichtung und Pflege von Zeitprogrammen. Interoperabilität in diesem Bereich setzt voraus, dass Stundenpläne für Datum, Tagesart und Zeit für Start und Stopp entsprechender Funktionen sowie das Verändern von Sollwerten bzw. analogen und binären/digitalen Parametern übertragen werden.

3.4.2 Nutzungszeiten-Liste Um einem Systemanbieter die korrekte Systemdimensionierung in Bezug auf Kalender-/Zeitfunktionen zu ermöglichen, muss aus dem LV der Umfang der beabsichtigten zeitabhängigen Funktionen hervorgehen, dies beinhaltet z. B. Nachtprogramme, Feiertags- und Ferienzeiten oder terminliche Sonderbehandlungen. - Festlegung aller Zeitfunktionen (pro Ein-/Aus-Zyklus bzw. Wertänderung für Parameter) in der GA-Funktionsliste

bei dem entsprechenden Datenpunkt, wenn der Errichter eines Systems den Zeitplan und Betriebskalender einrichten soll.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 24

3.4.3 Anzeige des Zeitplans BACnet ermöglicht die Durchführung bestimmter Aktivitäten auf Basis von Datums- und Zeittabellen. Diese Aktionen können Einrichtungen im GA-Netzwerk zum Start oder Stopp von Funktionen oder zur Veränderung von Sollwerten oder Parametern führen. Für Bediener ist es wichtig, zu sehen, welche Zeitaktionen geplant bzw. eingegeben sind. - Festlegung, der Bedienfunktionen in der GA-Funktionsliste, mit denen ein Bediener im GA-Netzwerk den Inhalt

des aktuellen Zeitplans mit Datum, Zeitpunkt und Aktion einsehen kann. - Festlegung, dass System- oder Controllerspezifische Parameter, welche den Zeitplan beeinflussen, dabei

erkennbar sind.

3.4.4 Verändern des Zeitplans BACnet ermöglicht die Änderung von Zeitplänen über das GA-Netzwerk. Diese müssen jedoch nicht in allen Fällen über das GA-Netzwerk bei heterogenen Systemen veränderbar sein. Sollte dieser Datenaustausch zwischen Systemen unterschidlicher Hersteller gefordert sein, muss diese Funktion neben dem Eintrag in der GA-Funktionsliste gesondert beschrieben werden, denn eine exakte Abstimmung der System- oder Controllerspezifische Parameter ist erforderlich. - Festlegung der Zeitplaneinträge, die über das GA-Netzwerk von einem berechtigten Bediener im Fremdsystem

veränderbar sind.

3.5 T - Trendaufzeichnung (en: trending)

3.5.1 Allgemeines Der Datenaustausch für „Trendaufzeichnung“ unterstützt die Darstellung von Zeit/(Mess-)Wert-Paaren mit einem spezifizierten Abtast-Zeitraster für einen spezifizierten Erfassungszeitraum. Die Trendaufzeichnung unterscheidet sich von der „gemeinsamen Datennutzung“ (siehe 3.2.3) darin, dass letztere Daten für Historisierung vorgesehen sind bei der die Aufzeichnungsintervalle grösser sein können als bei der Trendaufzeichnung. Die Interoperabilität in diesem Bereich ermöglicht die Einrichtung von Trendparametern und das nachfolgende Abrufen und Speichern der Werte für die Trenddarstellung.

3.5.2 Trend-Daten-Erfassung Wenn gefordert wird, dass Werte aus Datenkommunikationsobjekten im GA-Netzwerk für Trend-Diagramm-Darstellungen erfasst werden, muss das LV für die Bedien- oder Managementeinrichtung die Anzahl und Häufigkeit der geforderten Einträge festlegen, damit der Anbieter in der Lage ist, die erforderliche Speicherkapazität zu berechnen. - Festlegung der maximalen Anzahl von Werten als Funktionen der Datenpunkte (oder Merkmale von Objekt-

Typen), für welche eine Trenddaten-Erfassung erforderlich ist; o ANMERKUNG: Die Funktion Datenhistorisierung z. B. mit Datenbank für statistische Auswertungen

ist zu Unterscheiden von der Trendaufzeichnung für einen kurzen Zeitraum, z. B. für Einregulierung von Regelkreisen oder nach Reparaturen und Umbauten.

- Festlegung des minimalen Aufzeichnungsintervalls; o ANMERKUNG: Für Langzeit-Trendaufzeichnungen reichen ca. 6 Werte pro Stunde meistens aus.

- Festlegung der Zeitdauer, in der die gespeicherten Werte zur Darstellung zur Verfügung bleiben sollen. o ANMERKUNG: Ein bis zwei Jahre sind hierfür meist ausreichend.

Das LV muss festlegen, ob und wie gespeicherte Trend-Daten auf externe Datenträger archiviert werden sollen.

3.5.3 Trend-Diagramme Um einem Systemanbieter die korrekte Systemdimensionierung in Bezug auf Trendaufzeichnung zu ermöglichen, muss aus dem LV der Umfang der beabsichtigten Trend-Diagramme hervorgehen. - Festlegung der vom Errichter der Bedien-/Managementeinrichtungen zu implementierenden Trend-Diagramme.

Dies kann mit Hilfe der Funktionsliste erfolgen. Dabei kann in der Bemerkungsspalte auf das zugehörige Trend-Diagramm (Name) verwiesen werden.

o ANMERKUNG: In der Regel richten sich die Bediener selbst die benötigten Trend-Diagramme ein.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 25

3.5.4 Trend-Daten Anzeige und Speicherung BACnet ermöglicht die Übertragung von Trend-Daten, die in Feldgeräten erfasst wurden, über das GA-Netzwerk an Bedien- oder Managementeinrichtungen. - Festlegung, dass eine Bedieneinrichtung in der Lage sein muss, Trend-Daten zu erhalten, darzustellen, zu

speichern und zu drucken, z. B. mittels einer Tabellenkalkulations-Software.

3.5.5 Modifikation von Trendwertaufzeichnungs-Parametern Berechtigte Bediener müssen in der Lage sein, Trendaufzeichnungs-Parameter online einzustellen. - Festlegung der Änderbarkeit von Trendaufzeichnungs-Parametern durch berechtigte Bediener. Zu den

Parametern gehören das Zeitraster und die Dauer der Aufzeichnung.

3.6 DM - Device und Netzwerk-Management (Systemmanagement nach DIN EN ISO 16484-2)

3.6.1 Allgemeines Der Datenaustausch für Device und Netzwerk-Management betrifft Informationen zur Funktion und den Status der Devices im GA-Netzwerk. Die Interoperabilität in diesem Bereich sorgt für sichere Aussagen über die im GA-Netzwerk installierten Devices sowie über ihre funktionalen Möglichkeiten. Dies beinhaltet die Information über die Art der unterstützten Kommunikationsobjekte in diesen Einrichtungen. Ferner können die Kommunikation aktiviert und deaktiviert sowie die Zeiten synchronisiert werden (falls die Voraussetzungen dafür gegeben sind). Weiterhin kann ein Reset von Zentraleinheiten erfolgen. Verbindungen können bei Bedarf aufgebaut und Kommunikationskonfiguration verändert werden.

3.6.2 Anzeige von Informationen über den Device-Status Ein Bediener muss in der Lage sein, den Status jeder Einrichtung am Netzwerk anzufragen. - Festlegung im LV, dass eine Bedieneinrichtung jederzeit den Betriebszustand (en: status) jeder jedes Device im

GA-Netzwerk anzeigen kann.

3.6.3 Anzeige von Informationen über BACnet-Objekttypen Ein Bediener muss in der Lage sein, Informationen über ein BACnet-Objekt oder eine Gruppe von BACnet-Objekten anzuzeigen. - Festlegung im LV, dass eine Bedieneinrichtung jederzeit jedes normative Merkmal (en: property) von jedem

BACnet-Objekt im GA-Netzwerk anzeigen kann. - Festlegung im LV, dass eine Bedieneinrichtung die Anzeige von Objekt-Properties, gruppiert nach Objekttyp,

Objektlokation (z. B. ISP), Gewerk, etc. vornehmen kann.

3.6.4 Möglichkeit ein fehlerhaftes Device kommunikativ abzuschalten Wenn ein Sensor eine Fehlfunktion aufweist, muss ein Bediener in der Lage sein, die Kommunikation der entsprechenden Einrichtung bis zu Reparatur ruhig zu stellen. - Festlegung im LV, dass über eine Bedieneinrichtung im GA-Netzwerk eine Einrichtung bezüglich Alarm- und

Ereignismeldungen kommunikativ abgeschalten werden kann, bis die Wiederaufnahme der Kommunikation befohlen wird.

3.6.5 Möglichkeit der Uhrzeit-Synchronisation über ein GA-Netzwerk Es muss für einen Bediener möglich sein, Zeit-Synchronisations-Kommandos zu einer oder zu mehreren Einrichtungen im Netzwerk zu senden. Dies ist davon abhängig, ob ein Referenzzeitgeber im GA-Netzwerk vorhanden ist. Dieser kann die Synchronisation auch automatisch vornehmen. - Festlegung im LV, dass eine Bedieneinrichtung in der Lage sein muss, Uhrzeit und Datum für jede Einrichtung im

GA-Netzwerk, welche eine Uhrzeit-Funktion benutzt, zu verändern. Diese Systemfunktion gilt sowohl für einzelne Einrichtungen, als auch für Gruppen von Einrichtungen. Es können alle Einrichtungen im GA-Netzwerk gleichzeitig synchronisiert werden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 26

3.6.7 Möglichkeit Programme in einem Device ferngesteuert neu zu starten BACnet stellt ein Kommando zur Verfügung, welches es erlaubt, ferngesteuert die Programme der Zentraleinheit einer Automationseinrichtung zu einem Neustart der Software zu zwingen. - Festlegung im LV, dass eine Bedieneinrichtung im GA-Netzwerk die Möglichkeit haben muss, für alle

Einrichtungen, welche eine Neustart-Funktion unterstützen, das entsprechende BACnet-Kommando auszulösen.

3.6.8 Backup und Restore der Programme und Daten von Einrichtungen BACnet stellt die Möglichkeit zur Verfügung, die Konfigurationsdaten der Einrichtungen über das GA-Netzwerk zu sichern und zurückzuschreiben. Auch wenn nicht alle Einrichtungen diese Funktion unterstützen (z. B. bei Programmen auf ROM), ist es dennoch von Vorteil, diese Funktion zu benutzen, wenn sie verfügbar ist.

3.6.9 Ansteuerung von Halbroutern um Verbindungen aufzubauen und zu beenden BACnet „Halbrouter“ werden verwendet, um eine Verbindung zu entfernten Netzwerken und Einrichtungen, normalerweise auf Basis von temporären Telefon-Wähl-Verbindungen, aufzubauen. - Festlegung im LV, dass eine Datenschnittstelleneinheit in der Lage sein muss, nach Kommando eine Verbindung

zu einem entfernten GA-Netzwerk auf- und abzubauen. (Siehe STLB-Bau 070)

3.6.10 Abfrage und Ändern von Konfigurationen in Verbindung mit Halbroutern und Routern Bediener sollen in der Lage sein, die Konfigurationseinträge von Halbroutern und Routern, über den Aufbau der Kommunikation zu einem GA-Netzwerk, zu beeinflussen. - Festlegung im LV, dass über eine Bedieneinrichtung die Tabelleneinträge für den Aufbau von Verbindungen in

Halbroutern und Routern angezeigt und verändert werden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 27

4 Anwendung von BACnet-Objekten

4.1 Beschreibung der BACnet Objekttypen

4.1.1 Allgemeines Die BACnet-Objekttypen stellen die sichtbare und genormte Grundlage für die Interoperabilität von vernetzten GA-Systemen dar. Während die beschriebene Anwendung der IOBs, in Verbindung mit den Profilen des Anhangs A Einrichtungen spezifiziert, die über einen bekannten Umfang an BACnet-Funktionalität verfügen, ist die Anzahl und Art von BACnet-Objekten, abhängig von den geforderten Datenpunkten und den Funktionen für Überwachungs-, Steuer-, Regel- Optimierungs-, Management und Bedienaufgaben. Hierzu gehören z. B. die Anzahl von Meldungen, Zeitprogramm-Einträgen, dynamische Einblendungen usw. Dieser Abschnitt des Handbuchs gibt Hinweise zur Festlegung von BACnet-Objekten.

4.1.2 Die Datenelemente in den Objekt-Properties Die in der Norm festgelegten BACnet Objekttypen beschreiben mit einem Satz von eindeutig benannten und strukturierten Daten-Elementen, genannt Properties, durch Festlegung der entsprechenden Daten-Arten und Begrenzungen alle erforderlichen Informationen für eine programmgestütze Interpretation im Kontext Gebäudeautomation. Die Daten werden mit ebenfalls in der Norm festgelegten Diensten (Services) übertragen. Die für eine Interoperabilität mit eingeschränkter Systemfunktionalität erforderlichen Daten-Elemente sind normativ zwingend vorgegeben. Alle optionalen Properties erweitern den Interoperabilitätsbereich, wenn sie von den beteiligten Kommunikationspartnern gleichermassen implementiert werden. Es ist Aufgabe der Planung, den für ein Projekt insgesamt erforderlichen Interoperabilitätsbereich und daraus abgeleitet die BIBBs (BACnet Interoperabililitäts-Bausteine) für die unterschiedlichen Einrichtungen (Devices) nach Anhang B festzulegen. Beispiel: Binär-Eingabe Objekt aus DIN EN ISO 16484-5 (Erklärung der Identifier, Datenarten und Codes, siehe DIN EN ISO 16484-5:2004 – in Originalsprache und das Fachbuch "BACnet Gebäudeautomation 1.4" in Deutsch).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 28

Abb. 4-1 Normative Objekt Definition aus DIN EN ISO 16484-5

4.1.3 Die Informationstiefe Aus der Anzahl und Art der mit einem BACnet-Objekt übertragenen Properties ergibt sich die Informationstiefe pro Datenpunkt. Für die Massenermittlung der zu engineerenden Funktionen ist es wichtig, dass die geforderten Informationen eindeutig festgelegt werden. Als Hilfsmittel dient die bekannte GA-FL. Die Menge der einzelnen Informationen je Datenpunkt, die Informationstiefe, wird durch die Angabe der zu übertragenden (und darzustellenden) Objekt-Properties bestimmt. Da bei den BACnet-Objekttypen viele der Properties (Informationen) in der Norm nur als optional gekennzeichnet sind, muss detailliert festgelegt (und geprüft) werden, welche der optionalen Properties für die erforderliche Funktionserfüllung zuständig sind. Das neue Fachbuch „BACnet Gebäude-Automation 1.4“ gibt hierfür praktische Anleitungen.

4.2 BACnet Objekttypen und GA-Funktionen der EN ISO 16484-3 bzw. VDI 3814-1:2004 Die (bisher) 28 im BACnet-Standard festgelegten Objekttypen beschreiben mit einem Satz von eindeutig benannten und strukturierten Datenelementen, genannt Properties, durch Festlegung der entsprechenden Datenarten und -Begrenzungen alle erforderlichen Informationen für eine programmgestütze Interpretation im Kontext Gebäudeautomation. Die Daten werden mit ebenfalls im BACnet-Standard festgelegten Diensten (engl.: Services) übertragen. Die für eine Interoperabilität erforderlichen Datenelemente sind normativ zwingend vorgegeben. Alle optionalen Properties erweitern die funktionalen Eigenschaften eines BACnet-Objekts, wenn im Projekt erforderlich und den Interoperabilitätsbereich, wenn sie von den beteiligten Kommunikationspartnern gleichermaßen ausgeführt werden. Ein großes Problem der beteiligten Marktpartner war eine sinnvolle Übersetzung der Objekttyp-Bezeichnungen aus dem original BACnet-Standard. Durch erhebliche Unterschiede der

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 29

Systembetrachtungsweise, die in der jeweiligen Historie begründet liegen, würde eine 1:1 Übersetzung zu Fehlinterpretationen und Irrtümern führen. Die BACnet Interest Group Europe e.V. hat sich um einen einvernehmlichen Kompromiss in Zusammenarbeit mit dem deutschen Spiegelausschuss für CEN/TC247 und ISO/TC205 bemüht. Das Ergebnis wurde im "VDI-TGA/BIG-EU-Leitfaden für die Ausschreibung interoperabler Gebäudeautomation" veröffentlicht. Die Eingabe- und Ausgabe-Objekttypen (Datenpunkte) wurden im Deutschen ohne "Objekt" in der Bezeichnung festgelegt, während bei den komplexen Objekttypen die Bezeichnung "-Objekt" belassen wurde. Die "Wert"-Objekttypen sind "virtuelle Datenpunkte" und werden als kommunikative, gemeinsame Datenpunkte bezeichnet. Sie beziehen sich auch auf Informationen aus einem oder für ein Fremdsystem für die entsprechenden E/A-Funktionen in Abschnitt 2 der GA-Funktionsliste (GA-FL) nach dem VDI 3814-Standard.

4.3 Tabellarische Übersicht BACnet-Objekte – GA-Funktionen Die folgende Übersichts-Tabelle 4-01 zeigt auf, wie die BACnet-Objekttypen mit den Funktionen der GA-FL und deren Spezifikation in DIN EN ISO 16484-3 bzw. dem VDI-3814-Standard zusammenhängen.

Tabelle 4-01 – Zuordnung der (Standard-) BACnet-Objekttypen zu den genormten GA-Funktionen

BACnet-Objekttypen und GA-Funktionen EN – ISO 16484 / VDI 3814-1

BACnet-Objekttyp Originalsprache; Deutsche Übersetzung

Datenpunkttyp GA-Funktionsliste, (Abschnitt.Spalte)

Bedeutung und Eintragung in die GA-FL, (Abschnitt.Spalte)

1. Accumulator ACC Zählwerteingabe

Zählen, 1.4 Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.4, bzw. 7.1.

Für Messgeräte mit Impulsausgabe zum Zählen und Aufsummieren der Werte über die Zeit. Mit genauer Anpassung an den angezeigten Wert im physikalischen Zähler und entsprechender Voreinstellung für die Genauigkeit.

2. Analog Input AI Analogeingabe

Messen, 1.5 Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.5 bzw. 7.1.

Messen, z. B. Temperaturmessung,

3. Analog Output AO Analogausgabe

Stellen, 1.2 Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.2 bzw. 7.1.

Stellen, z. B. Stellbefehl für Regelventil,

4. Analog Value AV Analogwert

Virtueller analoger DP Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.2, 2.5, bzw. 7.1.

Digital dargestellter Analogwert, z. B. als Ergebnis einer Rechenoperation,

5. Averaging AVG Mittelwert

Virtueller analoger DP Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.2, 2.5, bzw. 7.1.

Digital dargestellter Wert aus Statistikfunktion als Mittelwert mit Minimum, Maximum und Varianz,

6. Binary Input BI Binäreingabe

Melden, 1.3 Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.3 bzw. 7.1.

Melden (z. B. Betriebszustands- Störungs- oder Alarmmeldung),

7. Binary Output BO Binärausgabe

Schalten, Stellen, 1.1 Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.1 bzw. 7.1.

Schalten (z. B. Schaltbefehl Ein/Aus, Stellbefehl Auf/Zu),

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 30

BACnet-Objekttypen und GA-Funktionen EN – ISO 16484 / VDI 3814-1

BACnet-Objekttyp Originalsprache; Deutsche Übersetzung

Datenpunkttyp GA-Funktionsliste, (Abschnitt.Spalte)

Bedeutung und Eintragung in die GA-FL, (Abschnitt.Spalte)

8. Binary Value BV Binärwert

Virtueller binärer DP Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.1, 2.3, bzw. 7.1.

Melden, Binärzustand, z. B. 0/1 aus einer logischen Verknüpfung,

9. Calendar CAL Betriebskalender

Systemparameter Feiertags- und Ferienliste, keine GA-Funktion, in 6.4 "Zeitabhängiges Schalten" enthalten.

10. Command CMD Gruppenauftrag

Virtueller DP Bei Fremdkopplung als Management-Kommunikationsfunktion 7.2.

Auftrag (Kommando) zur Ausführung (mehrerer) vordefinierter Aktivitäten (z. B. beauftragt von Optimierungsfunktionen 6.3 bis 6.13 und ggf. Bedienfunktion 8.2.

11. Device DEV Device

System-Grundparameter, (ggf. virtueller DP) Bei Fremdsystemkopplung z. B. für Watchdog-Funktionen als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Properties von Netzwerk-Teilnehmern (Geräte, Stationen und andere Einrichtungen), in denen BACnet-Objekte repräsentiert werden.

12. Event Enrollment EE Ereigniskategorie

System-Grundparameter In einer Standardbeschreibung für das Gesamtprojekt festzulegen.

Festlegung von Ereignisarten für spezifizierte Reaktionen auf Ereignisse/Alarme, in den GA-Funktionen enthalten.

13. Event Log ELOG Ereignis-Aufzeichnung

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Übertragen einer Liste mit Werten und Zeitstempel. Keine Funktion nach 7.3/7.4.

14. File FIL Datei

Systeminterne Funktion Dateiübertragung, z. B. für Konfigurationsdaten, Programme oder für Datensicherung (Archivieren), in GA-Software enthalten.

15. Global Group GGRP Globale Gruppeneingabe

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Gruppierung von Eingabewerten beliebiger Objekte im GA-Netzwerk, ist enthalten in den GA-Funktionen 3.6, 6.1, 6.2, 7.3, 7.4, 8.2.

16. Group GRP Gruppeneingabe

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Gruppierung der Eingabewerte beliebiger Objekte im selben Device, ist enthalten in den GA-Funktionen 3.6, 6.1, 6.2, 7.3, 7.4, 8.2.

17. Life Safety Point LSP Gefahrenmelder

Komplexes Eingabe-Objekt Bei Fremdkopplung als Management-Kommunikationsfunktion 7.2

Informationen über die Properties für Gefahrenmelde-Anwendungen im Netzwerk. Abgeleitete Aktionen sind entsprechende GA-Funktionen.

18. Life Safety Zone LSZ Sicherheitsbereich

Virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2

Zusammenfassung von Gefahrenmelder-Objekten, z. B. für Brandmeldelinien, Brandabschnitte, Nebenmeldezentralen etc. Anwendung für z. B. für 7.3, 7.4 (Protokolle), 8.2 dyn. Einblendung etc. Abgeleitete Aktionen sind entsprechende GA-Funktionen.

19. Loop LP Regler

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Properties (Attribute und Parameter) von Regelfunktionen, enthalten in den GA-Funktionen z. B. 5.1-5.8, 7.3, 7.4, 8.2.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 31

BACnet-Objekttypen und GA-Funktionen EN – ISO 16484 / VDI 3814-1

BACnet-Objekttyp Originalsprache; Deutsche Übersetzung

Datenpunkttyp GA-Funktionsliste, (Abschnitt.Spalte)

Bedeutung und Eintragung in die GA-FL, (Abschnitt.Spalte)

20. Multi-state Input MI Mehrstufige Eingabe

Melden, 1.3 Bei Fremdkopplung als gemeinsame, kommunikative Funktion je Stufe, 2.3 bzw. 7.1.

Logische Meldezustände als Zahl kodiert, z. B. Meldung: aus, langsam, schnell. Je Stufe ist eine GA-Funktion einzutragen.

21. Multi-state Output MO Mehrstufige Ausgabe

Schalten, Stellen, 1.1 Bei Fremdkopplung als gemeinsame, kommunikative Funktion je Stufe, 2.1 bzw. 7.1.

Logische Ausgabezustände als Zahl kodiert, z. B. Schaltbefehl: Aus, Stufe 1, Stufe 2, .... Je Stufe ist eine GA-Funktion einzutragen.

22. Multi-state Value MV Mehrstufiger Wert

Virtueller mehrstufiger DP Bei Fremdkopplung als gemeinsame, kommunikative Funktion je Stufe, 2.1, 2.3, bzw. 7.1.

Logische Zustände als Zahl kodiert, z. B. Zustandsdefinition 1,2,3, … Je Stufe ist eine GA-Funktion einzutragen.

23. Notification Class NC Meldungsklasse

System-Grundparameter In einer Standardbeschreibung für das Gesamtprojekt festzulegen.

Zeit- und Empfängerbezogene Zuordnung von Alarm- und Ereignismeldungen, in den betreffenden GA-Funktionen enthalten.

24. Program PR Programm

Komplexes Objekt Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Zugriff auf ein Programm in einem BACnet-Device, z. B. um dieses zu laden und zu starten. Das Programm muss zusätzlich beschrieben werden.

25. Pulse Converter PC Impulszähler Eingabe

Mengenzählung, 1.4, alternativ zu Zählwert-Eingabe. Bei Fremdkopplung als gemeinsame, kommunikative Funktion 2.4, bzw. 7.1.

Für Mengenzählung über ein gegebenes Zeitintervall, z. B. für Automobile, Wassermenge. Auch für periodische Leistungserfassung z. B. für Höchstlastbegrenzung, nicht jedoch für Abrechnungszwecke. Für Eich- bzw. Abrechnungszwecke siehe Nr. 1 Zählwert-Eingabe-Objekt

26. Schedule SCHED Zeitplan

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Zeitplan zur Ausführung wiederkehrender Aktivitäten und Festlegung einmaliger Ausnahmen, enthalten in der GA-Funktion 6.3, wird benötigt für 6.5 bis 6.7 und ggf. 6.12/6.13.

27. Trend Log TLOG Trendaufzeichnung

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Abonnement auf einen Wert für zeitweise ereignisorientierte Übertragung (COV-Reporting) für Trendaufzeichnung. I. d. R. Keine Funktion nach 7.3/7.4.

28. Trend Log Multiple TLOGM Mehrfachtrend-aufzeichnung

Ggf. virtueller DP Bei Fremdkopplung als virtueller DP mit Management-Kommunikationsfunktion 7.2.

Abonnement auf mehrere Werte für zeitweise ereignisorientierte Übertragung (COV-Reporting) oder "Lesen" von Werten für z. B. netzwerkübergreifende Trendaufzeichnung. I. d. R. Keine Funktion nach 7.3/7.4.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 32

4.4 Adressierungs- (Namens-) Konventionen BACnet-Objekte sind innerhalb eines Device eindeutig über einen 32-bit numerischen „object identifier“ (Adresse) identifiziert. Während dies den Zugriff über das GA-Netzwerk beschleunigt und den Projektierern beim Engineering ermöglicht, im Voraus zu wissen, wie viel Speicherplatz sie für diese Adressen freihalten müssen, ist ihre Benutzung für Bediener sehr unpraktisch. Aus diesem Grunde erlaubt BACnet auch, dass jedes Objekt über einen „Object_Name“ (z.B. Benutzeradresse) referenziert wird. Die Protokoll-Norm legt dabei nur eine minimale Länge von einem Zeichen für die Objektadrese (den Objektnamen) fest und fordert nicht explizit, dass dieser abänderbar bzw. überschreibbar ist, sobald ein Device fertig projektiert wurde. Damit wurde einfachen, anwendungsspezifischen Geräten/Controllern entgegen gekommen. Sowohl das Property „Object_Identifier“ (technische Adresse) als auch das Property „Object_Name“ (Benutzeradresse) müssen innerhalb eines BACnet Device eindeutig benannt werden. Eine weitere Einschränkung beim Deviceobjekt („device object“) ist, dass dessen technische Adresse und Benutzeradresse eindeutig innerhalb des gesamten GA-Netzwerkes sein müssen. Dies gilt auch bei Verwendung von temporären Wählverbindungen. Mit Ausnahme des Device-Objektes kann beim Engineering das Property „Object_Identifier“ ohne Rücksicht auf Probleme mit der Interoperabilität oder der Erweiterbarkeit des Systems frei konfiguriert werden. Der spezielle Fall des „device object identifiers“ ist im Kapitel 6.5 separat behandelt. Objektnamen sind als Benutzeradressen wie Datenpunkte für ein Gesamtsystem nach einer sinnvollen Struktur zu wählen. Die Struktur ist von Bauherrn vorzugeben. Diese Adressstruktur ist einheitlich für eine gesamte Liegenschaft oder für alle Liegenschaften des Bauherrn zu einzuhalten. Die Adressen (Objektnamen) werden in zwei komplett verschiedenen Zusammenhängen verwendet. Die eine Verwendung ist innerhalb von Automationsprogrammen, in denen für eine bestimmte Anwendung auf den Objektnamen Bezug genommen wird. Des Weiteren wird der Objektname als Benutzeradresse in Bedien- und Managementeinrichtungen verwendet. Dort kann ein Bediener damit einzelne Informationen („Properties“) eines BACnet Objektes aufrufen, und in eine Grafik oder eine Berichtstabelle einfügen. Im letzten Fall wird das Bedien- oder Managementsystem normalerweise eine Zuordnung der dort verwendeten Adressen zum „Object_Identifier“ (oder „Object_Name“), welcher in der BACnet-Automationseinrichtung benutzt wird, herstellen. Das grundsätzliche Prinzip im Aufbau einer Adressstruktur für Objekte und Devices ist, dass die Adressen mit so viel anlagenspezifischer Genauigkeit und Aussage gewählt werden, wie es die verfügbare Länge ermöglicht, z. B. ist die Bezeichnung Aussentemperaturfühler 1 der mehr kryptischen Bezeichnung „A1ZXC5“ vorzuziehen. Einige Systeme können die Klartextbezeichnung zusätzlich zur Benutzeradresse darstellen. Ein Beispiel einer strukturierten Adressierung wäre „G226.KL.KW.TEMP“, die Benennung der Temperatur des Kaltwasser-Erzeugungssystems, der Lüftung im Keller des Gebäudes 226. Bei der Aufstellung von Objektnamen, ist die bewährte Struktur nach VDI 3814-1 (bzw. GAEB 070) sehr hilfreich. Es ist für jedes Projekt eine Adressstruktur mit Abkürzungssystem zu entwickeln bzw. vorzugeben (z.B. nach VDI 3814-1) für die Gebäude oder Gebäudeteile, die Gewerke und Anlagen bis hin zu den Objekt-Properties von Datenpunkten. Dieses muss von allen beteiligten Herstellern genutzt werden. - Die Trennung der Strukturelemente erfolgt durch besondere Zeichen, z. B. durch Punkte. - In den eingesetzten GA-Systemen müssen die vorgesehenen Objekt-Adress Properties

(„Object_Name“) und deren Zeichenanzahl konfigurierbar sein. - Diese Objekt-Adress-Properties müssen auch in allen GA-System-Anwendungen, wie in Grafiken,

Berichten und Alarm-Texten und an allen Stellen, an denen eine Objekt-Adresse verwendet wird, in gleicher Weise verwendet werden.

- Ein Bediener soll jederzeit die Zuordnung einer im GA-System verwendeten Benutzeradresse (z.B. mit Klartext) zu einer Objekt-Adresse, welche im Fremdsystem verwendet wird, ermitteln können.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 33

Beispiel für eine Adressstruktur, die für ein Liegenschaftsportfolio unter Einbeziehung von CAFM geeignet ist: Das Beispiel setzt sich aus Orts-, Anlagen- und GA- Kennung zusammen, wobei nicht alle Strukturelemente immer dargestellt werden müssen (z.B. bei einer Raumautomation oder je nach „Sicht“ auf das Objekt):

000 AAA 00 AAA 00 AA AA 00 AA 00

Objekt

Gebäude / Bauteil

Geschoß

Gewerknach DIN 276

Anlage undAnlagennr.

Zonen-nummer

Anlagenteilund Anlagen-teilnummer

Datenpunktartund Nummer

Einzelgerätund Einzel-gerätnummer

00

Ortskennung Anlagenkennung GA-Kennung

A000 000

Raum

00

Siehe auch Beispiel in Anhang D (Beiblatt 070-3)

4.5 Systemengineering und Diagnose über BACnet Dienste Eine Besonderheit von BACnet ist die Möglichkeit, die Arbeitsweise von Regelfunktionen in Fremdsystemen durch Beeinflussung der Properties des Reglerobjekts zu verändern. Gleichzeitig können die Resultate bezogen auf die Funktion beobachtet werden. Diese Funktionalität ist von besonderer Bedeutung während der Inbetriebnahme oder für die Diagnose von Problemen und für den Nachweis der Funktion. Um den Aktualwert (Present_Value) eines Objektes von dem darunter liegenden Prozess zu entkoppeln und ihm einen bestimmten Wert vorzugeben, muss das Objekt zuerst ausser Betrieb genommen werden, was durch Setzen des „out of service“-Property auf „wahr“ (true) erfolgt. Das „out of service“-Property wird für alle Ein-Ausgabe- und Wert-Objekte sowie für das Reglerobjekt und das Programmobjekt zur Verfügung gestellt. Um auch sehr einfachen, anwendungsspezifischen Geräten entgegenzukommen, verlangt BACnet nicht, dass das „out of service“-Property schreibbar ist. In solchen Geräten wird das „out of service“-Property von device-internen Funktionen festgelegt und gegebenenfalls verändert. Dabei kann es sich um herstellerspezifische Konfigurationswerkzeuge handeln. Eine Inbetriebnahme und Diagnose über das BACnet-Netzwerk ist nur möglich, wenn das „out of service“-Property für das Diagnosesystem schreibbar ist. - Wird die Möglichkeit des Engineering über BACnet-Dienste gefordert, muss das „out of service“-

Property bei allen dafür vorgesehenen Objekten einstellbar (überschreibbar) sein. Diese Festlegung ist im LV durch eine Textergänzung bei der Standardbeschreibung des Systems zu dokumentieren.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 34

4.6 Benutzung der Objekt-Beschreibung Alle BACnet-Objekte haben ein Property für einen optionalen Beschreibungstext dessen Länge und Inhalt nicht vorgegeben bzw. eingeschränkt ist. Der Zweck dieses Objekt-Property („Description“) ist, einem Bediener oder Servicetechniker Informationen über die Verwendung oder Anwendung eines bestimmten Objektes in einer BACnet-Einrichtung zu beschreiben. Das Beschreibungs-Property ist optional, weil Text einen relativ hohen Anteil von Speicher belegen kann und damit die Möglichkeiten von einfachen Geräten überfordert würden. Alternativ können die Informationen des Objekt-Beschreibungs Property ausserhalb der betroffenen BACnet-Einrichtung abgespeichert werden, um Geräte mit einer begrenzten Speicherfähigkeit zu entlasten. Dies kann z. B. in einer Bedien- oder Managementeinrichtung („Operator Workstation“) erfolgen. . In jedem Fall ist eine ausgefüllte Objekt-Beschreibung insbesondere beim Hardware-Objekt in der Projektdokumentation sehr wichtig. - Im LV ist eine Dokumentation der Objektbeschreibungen im Rahmen des Objekt-Beschreibungs-

Property in Form einer Textergänzung bei den Systemmerkmalen festzulegen.

4.7 Anmerkung zu Kommunikations-Objekttypen

4.7.1 Komplexe Kommunikationsobjekte Nach DIN EN ISO 16484-3 erfordern alle Objekttypen, die über E/A-Objekte hinausgehen („komplexe Kommunikationsobjekte“), eine besondere Abstimmung zwischen den System-Errichtern bei einer heterogenen Systemkopplung und eine besonders sorgfältige Dokumentation wegen evtl. Gewährleistungsansprüche. Ziel der Abstimmung der Objekt-Properties ist es, eine konsistente Verwendung in einem Projekt sicherzustellen. In DIN EN ISO 16484-5 Datenprotokoll wird die Verwendung und Behandlung dieser Objekt-Properties als "local matter" bezeichnet, d. h. eine projektspezifisch von Fall zu Fall zu lösende Aufgabe. Für die Systemparameter gibt es keine speziellen GA-Funktionen nach Definition für die GA-FL. Bei einem Datenpunkt mit mehrstufiger (multistate) Ein-/Ausgabe wird je erforderlichem Zustand für die Hardware-Bestimmung eine Funktion in der GA-FL eingetragen. (Eine Dauer- oder Impulskontaktgabe ist dabei zu beachten, siehe Anmerkung Nr. 1 auf der GA-FL).

4.7.2 Analoge Eingabe, Ausgabe und Analogwert - COV Alle analogen Objekttypen haben die Fähigkeit, Wertänderungen zu melden, indem sie die COV Reporting Methode benutzen. Dazu muss der Wert von einer anderen BACnet-Einrichtung (als Client) abonniert werden. - Im LV wird die Unterstützung der Wertübertragung nach dem COV Verfahren gefordert, damit alle

analogen Objekte (Eingabe, Ausgabe und Wert) konsequent als Änderungsinformationen übertragen werden. Der Schreibzugriff auf den Schwellenwert für die Übertragung (COV_Increment) über die BACnet Dienste ist festzulegen.

4.7.3 Binäre Eingabe - Zustandstexte Binäre Eingaben verfügen über zwei Objekt-Properties deren Inhalte bei einem Projekt vor dem Engineering abzustimmen sind. - Im LV ist die abgestimmte Festlegung aller Zustandstexte für die binären Datenpunkte in Form der

Objekt-Properties Inactive_Text und Active_Text vorzugeben. Beispiele sind "Ein", "Aus", "Gestört", "Stopp", "Offen", "Geschlossen" etc.

4.7.4 Binäre Ausgabe

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 35

4.7.4.1 Befehlsausführkontrolle Binäre Ausgaben verfügen zusätzlich zu den Properties Inactive_Text und Active_Text (siehe binäre Eingabe) das Property Feedback_Value, deren Inhalt ebenso bei einem Projekt vor dem Engineering abzustimmen ist. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion Befehlsausführkontrolle in der GA-

Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt. 4.7.4.2 Betriebsstundenerfassung Binäre Ausgaben verfügen zusätzlich über optionale Properties, die dazu verwendet werden können, die Anzahl der Schaltzyklen und die aufsummierte Laufzeit zu übertragen. Wird diese Funktion für aufsummierte Laufzeiten (accumulated run times) gefordert, sind ebenso die Objekt-Properties Elapsed_Active_Time und Time_Of_Active_Time_Reset gefordert. Dabei muss das Property Elapsed_Active_Time schreibbar sein, damit die gezählte Laufzeit zurücksetzbar ist. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion Betriebsstunden-Erfassung und/oder

die Befehlsausführkontrolle in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt.

4.7.4.3 Minimale Ein- und/oder minimale Aus-Zeit Binäre Ausgaben verfügen zusätzlich über optionale Properties, für die minimale Ein- und/oder minimale Aus-Zeit als Property Minimum_On_Time und Minimum_Off_Time, deren Inhalt bei einem Projekt vor dem Engineering abzustimmen ist. Die Anwendung ist z. B. für die Höchstlastbegrenzung vorgesehen. - Im LV ist die projektspezifische Abstimmung zur Festlegung aller erforderlichen Zeitbegrenzungen für

die binären Ausgabe-Datenpunkte in Form der Objekt-Properties Minimum_On_Time und Minimum_Off_Time vorzugeben, insbesondere wenn Optimierungsprogramme eingesetzt werden.

4.7.4.4 Ereigniszählung Binäre Ausgaben verfügen zusätzlich über optionale Properties, für die Zählung der Schalthäufigkeit als Property Change_Of_State_Count vorgesehen. Wird diese Funktion gefordert, sind ebenso die Objekt-Properties Change_Of_State_Time (Zeitstempel für einen Zustandswechsel) und Time_Of_State_Count_Reset (Zeitstempel für das Rücksetzen des Zählers für die Zustandswechsel) gefordert. Dabei muss der Change_Of_State_Count schreibbar sein, so dass der Zählerstand zurücksetzbar ist. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion Ereigniszählung in der GA-

Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt.

4.7.5 Binärwert (Binary Value) Für das Objekt eines virtuellen oder gemeinsamen, kommunikativen Datenpunkts kann es erforderlich sein, folgende Properties festzulegen: Inactive_Text und Active_Text, Minimum_On_Time und Minimum_Off_Time, Change_Of_State_Time, Change_Of_State_Count, Elapsed_Active_Time und Time_Of_Active_Time_Reset. - Die Festlegung im LV erfolgt wie bei 4.6.3 Binäre Ausgabe.

4.7.6 Betriebskalender Objekt Kalender sind Objekte, die eine Liste mit bestimmten Daten, Zeitspannen oder Kombinationen aus Monat, Woche und Tag enthalten. Ein Beispiel hierfür wäre: "Der erste Dienstag eines jeden Monats". Eine typische Anwendung des Objektes Betriebskalender ist das Ablegen von Feiertagen, Betriebsferien oder von besonderen Ereignissen, an denen ein besonderer Zeitplan (Schedule) gültig ist. BACnet legt weder die Anzahl der Kalender Objekte fest, noch die Anzahl der Einträge, die ein Betriebskalender mindestens zulassen muss. BACnet legt auch nicht fest, ob die Einträge im Betriebskalender über das Netzwerk verändert werden können.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 36

Sind Einträge für das zeitabhängige Schalten nach DIN EN ISO 16484-3 gefordert, sind alle zur Eingabe eines Kalendereintrages erforderlichen Datenarten für das Property Date_List zu unterstützen. Dies sind einzelne Tage, Zeitspannen, spezielle Wochen und Tage innerhalb eines Monats. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion Zeitabhängiges Schalten in der GA-

Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt. Falls keine Zeitzuordnungen per Funktionsliste gefordert sind, soll die Systemsoftware für den Kalender pro BACnet-Automationseinrichtung eine Kapazität von wenigstens 10 Einträgen erlauben. Von jeder BACnet Workstation im Netzwerk soll lesender und schreibender Zugriff auf das Kalenderobjekt möglich sein.

4.7.7 Reglerobjekt Reglerobjekte dienen dazu, Regelfunktionen und deren Parameter darzustellen und zu beeinflussen. Soll die Einstellung der Regelparameter über das GA-Netzwerk erfolgen, muss die Verwendung des BACnet Reglerobjekts gefordert werden. Dabei müssen die Reglerparameter, die zur Optimierung des Regelverhaltens benötigt werden, schreibbar sein. Dabei handelt es sich um folgende Parameter: Update_Interval, Setpoint (Sollwert), Proportional_Constant (P-Bereich, Xp), Integral_Constant (Nachstellzeit), Derivative_Constant (Vorhaltezeit) und Bias. Zusätzliche Parameter werden von der Norm nicht unterstützt. Falls die jeweilige Anwendung den Schreibzugriff auf weitere Parameter erforderlich macht, so muss dies im LV explizit gefordert und beschrieben werden. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion komplexe Objekttyp zum Datenpunkt

der Regelgrösse in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt.

4.7.8 Mehrstufige Ein- und Ausgabe, mehrstufiger Wert Mehrstufige EIN-/Ausgabe Objekte verfügen über Objekt-Properties State_Text für jeden der möglichen Zustände, die der Aktualwert als Property Present_Value annehmen kann. Zusätzlich verfügen mehrstufige Ausgbeobjekte über das Property Feedback_Value. Alle mehrstufigen Objekttypen haben die Fähigkeit, Wertänderungen zu melden, indem sie die objekteigene (intrinsic reporting) Methode für COS (Change of State) benutzen. Die Inhalte der Objekt-Properties State_Text sind bei einem Projekt vor dem Engineering abzustimmen sind. - Im LV wird die Anzahl der Stufen durch die Zuordnung der Anzahl Funktionen für physikalische oder

kommunikative binäre Ausgabe Schalten/Stellen bzw. binäre Eingabe Melden und die Zuordnung bei Ein-/Ausgabe Objekttyp zum Datenpunkt in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position gefordert.

4.7.9 Zeitplanobjekt Zeitplanobjekte bieten die Möglichkeit, Zustände oder Werte basierend auf Datum und Uhrzeit zu verändern. Dabei wird typischerweise auf virtuelle Datenpunkte wie „Betriebsart Gesamtanlage“, auf Betriebsparameter wie Sollwerte oder auf physikalische Ausgabefunktionen eingewirkt. Ein Zeitplan kann dabei mehreren Datenpunkten zugeordnet werden wobei dann jeder Datenpunkt zu einer bestimmten Zeit auf den gleichen Wert geschaltet wird. Zum Beispiel können auf diese Weise mehrere Lüftungsanlagen von Montag bis Freitag jeweils morgens um 7.00 Uhr ein- und abends um 18.00 Uhr ausgeschaltet werden. Das Protokoll BACnet sagt nichts darüber aus, wie viele Schedule Objekte eine BACnet Lösung unterstützen sollte und auch nichts darüber, ob irgendwelche der Properties über BACnet beschreibbar sind. Die Ausschreibung muss daher festlegen, dass von jeder BACnet Workstation die Einträge im Zeitplan verändert werden können. - Im LV wird die die Zuordnung der Zeitplanobjekte durch die Zuordnung der GA-Funktion komplexe

Objekttyp und Festlegung der Anzahl Schaltpaare bei zeitabhängiges Schalten zum Datenpunkt in der GA-Funktionsliste dokumentiert und mit den entsprechenden LV-Positionen festgelegt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 37

- Bei heterogenen Systemen wird dem System, in welchem die Dienstleistung und

Anwendungssoftware für die Einrichtung von zeitabhängigem Schalten gefordert ist, durch Festlegung der Anzahl Schaltpaare (z. B: ein/aus) in der GA-Funktionsliste und mit der entsprechenden LV-Position zugeordnet.

- Im LV ist die projektspezifische Abstimmung zur Festlegung aller erforderlichen Schaltzeiten vorzugeben, insbesondere wenn Optimierungsprogramme eingesetzt werden, ggf. sind in einem Beiblatt genaue Angaben zu den geforderten Funktionen des Zeitschaltprogramms zu machen.

4.8 Erzeugen von BACnet Objekten im laufenden Betrieb (Dynamic Object Creation) BACnet bietet die Möglichkeit, neue Objekte dynamisch zu erzeugen, also nach dem eigentlichen Engineering Prozess. Theoretisch können mit diesem Verfahren alle Objekttypen erzeugt werden. In der Praxis dient diese Funktionalität hauptsächlich dazu, Objekte wie Mittelwert, Betriebskalender, Ereigniskategorie, Gruppeneingabe, Meldungsklasse, Zeitplan und Trend Aufzeichnung zu erzeugen. - Im LV wird durch eine Textergänzung bei der Standardbeschreibung für das System festgelegt, dass

geforderte Objekte wie Mittelwert, Betriebskalender, Ereigniskategorie) Gruppeneingabe, Meldungsklasse, Zeitplan und Trend Aufzeichnung im Betrieb des Systems (dynamisch) erzeugt werden können.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 38

5 Anwendung von BACnet Diensten (Services)

5.1 Prioritätensteuerung für interoperable Aufträge/Befehle Eine Stärke des BACnet Protokolls ist die Verwendung des Verfahrens für die Priorisierung von Befehlen (command priority). Damit wird es möglich, die verschiedenen Befehle wie Start- und Stoppbefehle, Sollwertverstellung etc., zu priorisieren und die Reihenfolge der Befehlsausführung vorhersehbar zu gestalten. Den verschiedenen Prozessen/GA-Funktionen oder Datenpunkten wird eine Prioritätenebene (command priority level) zugeordnet. In BACnet ist folgendes Prioritätenschema bereits festgelegt (siehe Tabelle 1):

Prioritäten- ebene

Anwendung Prioritäten- ebene

Anwendung

1 Manual-Life Safety (Sicherheit – Hand)

9 Frei Verfügbar

2 Automatic-Life Safety (Sicherheit - Automatik)

10 Frei Verfügbar

3 Frei Verfügbar 11 Frei Verfügbar 4 Frei Verfügbar 12 Frei Verfügbar 5 Critical Equipment Control

(Kritische Anwendung) 13 Frei Verfügbar

6 Minimum On/Off (Ein/Aus) 14 Frei Verfügbar 7 Frei Verfügbar 15 Frei Verfügbar 8 Manual Operator

(Hand) 16 Frei Verfügbar

Tabelle 5-1: Standard BACnet Befehlsprioritäten Hinweis: Die Prioritäten 3, 4, 7 und 9 - 16 stehen für projektspezifische Zuweisungen zur Verfügung, sie sind ggf. festzulegen. Die Planungs- oder Engineering-Aufgabe besteht darin, (1) zu entscheiden, welche Prozesse/Funktionen in das Prioritätenschema aufgenommen werden

sollen und (2) zu entscheiden, welche relative Bedeutung ein Datenpunkt/Prozess bekommen soll, d. h. welcher

Prioritätenebene er zugewiesen werden soll, damit er nur von einer definierten Befehlspriorität beeinflusst werden kann.

Folgende Prozesse/Funktionen sind ggf. mit einer Prioritätensteuerung zu versehen, welche für den gesamten BACnet Systemverbund gilt: - Ereignisabhängiges Schalten, - Zeitabhängiges Schalten; - Gleitendes Ein-/Ausschalten, - Zyklisches Schalten, - Netzersatzbetrieb, - Netzwiederkehrprogramm, - Höchstlastbegrenzung, - Tarifabhängiges Schalten.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 39

5.2 Ereignis Management in BACnet Systemen

5.2.1 Zuweisung von Ereignis Prioritäten BACnet bietet die Möglichkeit, jeder Transaktion für die eine automatische Meldung erwünscht ist, eine numerische Priorität zuzuweisen. Solche Transaktionen sind TO-OFFNORMAL, TO-FAULT und TO-NORMAL. Die Bedeutung jeder dieser Transaktionen hängt von dem hinterlegten Algorithmus ab, der dem betreffenden Ereignis-Eingang nachgeschaltet ist. Die gängigen Algorithmen sind normativ präzise in BACnet beschrieben. Dabei handelt es sich um folgende Ereignisse: - COB Änderung einer Bitfolge (Change of Bitstream), - COS Zustandsänderung (Change of State ), - COV Wertänderung (Change of Value), - Befehl nicht erfolgreich (Command Failure), - Gleitender Grenzwert (Sliding (or floating) Limit) und - Bereichsüberschreitung (Out of Range). Der Wertebereich für die Prioritäten reicht von 0 bis 255 wobei 0 die höchste und 255 die niedrigste Priorität bedeutet. Typischerweise wird auf Projekten nur eine kleine Anzahl dedizierter Werte wie z. B. "255, 128, 0" verwendet, deren Wichtigkeit dann "hoch, mittel und niedrig" bedeutet. Für jeden gesamten BACnet Systemverbund müssen die Prioritäten bei Planung oder Projektierung festgelegt werden. Alarm-Ereignisse werden in BACnet entweder durch Objekte erzeugt, die objekteigenes Melden (Intrinsic Reporting) unterstützen oder durch Ereigniskategorieobjekte (Event Enrollment Objects). Folgende Objekttypen unterstützen das objekteigene Melden (Intrinsic Reporting): - Analoger Ein- und Ausgang und Wert, - Binärer Ein- und Ausgang und Wert, - mehrstufiger Ein- und Ausgang sowie das - Reglerobjekt. Nur der Aktualwert (Present_Value) oder die Status_Flags können in das objekteigene Melden (Intrinsic Alarming) einbezogen werden. Für Ereigniskategorieobjekte gilt: Die Standard-Algorithmen können auf jedes Objekt-Property angewendet werden. Die Verteilung von Ereignis/Alarmnachrichten wird über die so genannten Mitteilungsklassen (Notification Classes) geregelt. Diese werden im nachfolgenden Abschnitt beschrieben. Ein Parameter der Alarmmeldung (alarm notification) ist die numerische Priorität. Die Priorität ist ein Objekt-Property der Ereigniskategorie- (Event Enrollment) Mitteilungsklassen- (Notification Class) Objekte. BACnet legt nicht fest, wofür die Priorität eingesetzt werden soll. Es ist Aufgabe der Planung oder Projektierung, die Alarmprioritäten den tatsächlich vorkommenden Alarmen zuzuweisen und die Reaktionen darauf festzulegen. Reaktionen können sein: - Ausgabe der Meldung auf einen Drucker, - Auslösen eines akustischen oder optischen Signals, - Erstellen eines Berichts mit den gesammelten Alarmen einer bestimmten Priorität usw. - Im LV werden durch eine Textergänzung bei der Standardbeschreibung für das System die Anzahl der

Meldeklassen (Prioritäten) für Ereignisse/Alarme und die Aktionen je Meldeklasse festgelegt.

5.2.2 Festlegen von Meldeklassen (Notification Classes) Wie im letzten Abschnitt angedeutet, können mit BACnet Informationen über Ereignisse/Alarme abhängig von ihrer Art, dem Wochentag oder von der Uhrzeit zu verschiedenen Zielen geleitet werden. BACnet erreicht dies durch die Einrichtung von Meldeklassen (Notification Class Objects). Eine Meldeklasse wird

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 40

durch Zahl (integer) dargestellt. Aufgrund der jeweiligen Meldeklasse einer Ereignismeldung wird diese den Empfängern zugestellt, die für diese Meldeklasse im Meldeklassen-Objekt eingetragen sind. Im einfachsten Falle existiert für ein System nur eine Meldeklasse, die fest eingerichtet ist und besagt, dass alle Meldungen immer, also 24 Stunden pro Tag an einen bestimmten Empfänger geschickt werden. In einer typischen Anwendung gibt es aber mehrere Empfänger, die aber nur jeweils Meldungen über bestimmte Ereignis/Alarmklassen erhalten sollen und das vielleicht auch nur zu bestimmten Tageszeiten. Das Personal einer Leitwarte soll vielleicht alle Alarme während der Frühschicht und während des Tages erhalten. Da die Leitwarte aber während der Nachtschicht nicht besetzt ist, werden die Alarme dann für die Rufbereitschaft über ein Mobiltelefon (oder Pager) ausgegeben oder an eine ständig besetzte Stelle weitergeleitet. Ein Muster für das erforderliche Beiblatt befindet sich auf der STLB-Bau-CD bzw. unter http://www.gaeb.de/LBanhang.html. - Im LV wird durch Darstellung einer schematischen Systemstruktur als Beiblatt die Möglichkeit

gegeben, die Empfänger bestimmter Alarmklassen und ihre Prioritäten zu kennzeichnen (z.Β.: „Beiblatt 070-1_Muster_Systemaufbau.pdf). Weiterhin werden durch eine Textergänzung bei der Standardbeschreibung für das System die Ereignis/Alarmklassen und deren Tag/Zeit- Zuordnungen festgelegt, bzw. deren Festlegung bei der System-Projektierung gefordert.

5.2.3 Ereignis-Anweisungstexte (Event Notification Message Texts) Wenn ein Alarm oder Ereignis auftritt, so signalisiert BACnet dies durch eine Meldung (Event Notification). Diese Meldungen enthalten bereits die wichtigsten Informationen über das Ereignis nämlich "Was", "Wann" und "Wo". BACnet stellt als weitere Möglichkeit die Übertragung des Ereignis-Anweisungstextes (Message Text) bereit. In einigen Systemen ist es Aufgabe der Bedien- oder Managementeinrichtungen (Workstation Software), eine verschlüsselte Meldung (alarm identifier) in einen sinnvollen Text zu übersetzen und zur Anzeige zu bringen. Aber es gibt auch Automationsstationen oder Feldgeräte, die den Ereignis-Anweisungstext zusammen mit den anderen Informationen über das Ereignis melden. In beiden Fällen ist es durchaus sinnvoll, den Inhalt und das Format der Meldung zu spezifizieren. Abgesehen von den Einzelheiten in Bezug auf die Störung/den Alarm selbst, können die Ereignis-Anweisungstexte dazu benutzt werden, dem Bediener Hinweise über notwendige, einzuleitende Massnahmen mitzuteilen. Die Meldungstexte können zum Beispiel den Namen und die Telefonnummer eines bestimmten Servicetechnikers enthalten. Diese Texte können auch Anweisungen an das Personal geben, im Sinne einer Plausibilitätsprüfung bestimmte andere Datenpunkte, die im Zusammenhang mit der als gestört gemeldeten Anlage stehen, zu überprüfen. Auszug aus STLB-Bau 10/2003 070 TLG: Software für Bedienfunktionen Psch: …….. - Ereignis-Anweisungstexte zur Ausgabe auf Bildschirm/Drucker im Anschluss an eine kommende Ereignismeldung entsprechend der Zuordnung von Anweisungstexten zu Benutzeradressen, Anweisungstexte, Anzahl ....................................................... mit Zeichen, Anzahl ....................................................... --------- TLG: Funktionen - GA STLB-Bau 10/2003 070 St:… Bedienfunktion, Ereignis-Anweisungstext, bis 80 Zeichen. Legende: TLG = Teilleistungsgruppe

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 41

- Im LV wird die Forderung durch die Zuordnung der GA-Funktion Ereignis-Anweisungstext zum

Datenpunkt in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position bei Nennung der geforderten Anzahl Zeichen (80 oder 256) festgelegt.

- Ausserdem ist insbesondere bei heterogenen Projekten die projektspezifische Abstimmung zur Festlegung aller erforderlichen Ereignis-Anweisungstexte vorzugeben.

5.3 Festlegung der Benutzer-Zugriffskontrolle (Assigning Levels of Authority to Certain Operators) Die Rückverfolgung von Alarmquittierungen ist ein wichtiger Aspekt des technischen Facility Managements. In BACnet-Systemen können Einrichtungen so konfiguriert werden, dass dort Alarmquittierungen ausschliesslich von bestimmten Bedienern möglich sind. Dazu können den einzelnen Benutzern jeweils unterschiedliche Zugriffsberechtigungen entsprechend ihrem Verantwortungsbereich zugewiesen werden. Bei BACnet gibt es einen optionalen Passwortschutz für die Systemverwaltung über das Netzwerk (Remote Device Management) mit den Diensten „DeviceCommunicationControl“ und „ReinitializeDevice“. Der erste Dienst ermöglicht dem Personal an einer BACnet Operator Workstation, die Kommunikation eines BACnet Device abzuschalten, wenn es z. B. durch einen defekten Fühler fortlaufend unsinnige Meldungen erzeugt. Der zweite Dienst kann ein Device im GA-Netzwerk zu einem Kalt- oder Warmstart auffordern. In beiden Fällen kann die Verwendung von Passworten vereinbart und in den Einrichtungen hinterlegt sein. Diese Passworte können bis zu 20 Zeichen lang sein. - Im LV werden durch eine Textergänzung bei der Leistungsbeschreibung für das System die Anzahl

der Zugriffsschutzebenen und die Anzahl der Passworte (Benutzer) festgelegt (siehe Beispiel). - Die Anzahl Zeichen für Passworte ist ggf. in einem Beiblatt festzulegen. - Für die Zugriffskontrolle für die Systemverwaltung über das Netzwerk (remote device management)

sind ggf. in einem Beiblatt genaue Angaben zu machen. In diesem Falle ist die projektspezifische Abstimmung zur Festlegung aller erforderlichen Vereinbarungen, z B. die dynamische Passwortzuweisung im laufenden Betrieb, vorzugeben.

Ausschnitt aus GAEB LB 070 Gebäudeautomation

Software für Bedien- und Managementfunktionen – GA psch:… Systemzugriffsschutz zum Schutz gegen unbefugte Bedienung und zur Steuerung der zugelassenen Bedienfunktionen pro Bediener, wobei eine höhere Zugriffsebene die Rechte aller niedrigeren Ebenen einschliesst, für bis zu 16 Zugriffsebenen, für bis zu 8 gewerk- oder ortsbezogene Zugriffsbereiche, für bis zu 1000 Passworte, An-/Abmelden der Bedienfreigabe durch den Bediener bzw. automatisches Abmelden nach Ablauf einer parametrierbaren Zeitspanne ohne Bedieneraktivitäten. ---------… mit Ein-/Mehrplatzbedienung sowohl zur direkten Ansteuerung eines einzelnen Bedienplatzes als auch zur Ansteuerung örtlich verteilter Bedienplätze über ein Fremdnetz gemäss Einzelbeschreibung, Einzelbeschreibungs-Nr 4711, Zusätzliche technische Vertragsbedingungen zu DIN EN ISO 16484-5 (BACnet) Kapitel 0815. mit Lizenz für Bedienstation im systemfremden Netzwerk, Anzahl 3

5.4 Verarbeitung von Wertänderugen – COV (Change of Value Processing) Eine Stärke von BACnet ist die Unterstützung des Übertragungsverfahrens nach Wertänderung COV (Change of Value). Das bedeutet, dass man bestimmte Objekttypen so konfigurieren kann, dass sie eine Information absetzen, wenn sich ihr Aktualwert um einen definierten Schwellenwert geändert hat oder wenn sich ihr Status ändert. Unter Status (status flag), werden Informationen verstanden, welche die Bedeutung eines Zustands anzeigen, wie Alarm, Fehler, Handbetrieb oder nicht betriebsbereit.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 42

COV-fähig sind die Objekte analoge, binäre und mehrstufige Eingabe, Ausgabe und Wert (als virtueller Datenpunkt) sowie das Reglerobjekt. Besonders effizient ist die Übertragung bei Wertänderung (COV notification) zum Beispiel für die Versorgung eines Anlagenbildes mit dynamischen Einblendungen (Echtzeit-Daten) oder zur Vermeidung von unnötiger Netzwerkbelastung. Das COV Verfahren ist grundsätzlich dem zyklischen Abfragen von Datenpunkten/Objekten vorzuziehen.

5.4.1 Abonnement für die COV-Mitteilungen (Subscribed COV Notifications) Um am Übertragungsverfahren nach Wertänderung (COV) für ein bestimmtes Objekt teilzunehmen, muss der Einrichtung, die den gewünschten Datenpunkt enthält, ein Abonnement-Auftrag (subscription request) zugestellt werden. - Im LV wird durch eine Textergänzung bei der Leistungsbeschreibung für das System festgelegt, dass

durch den BACnet Dienst „Abonnement für die COV-Teilnahme“ die Informationen der geforderten Datenpunkte (gem. Funktonsliste) übertragen werden. BIBB: DS-COV-A/B, siehe Anhang A.

- ANMERKUNG: Wenn die Abonnement-Aufträge vom Auftragnehmer eingerichtet werden sollen, sind diese in der GA-Funktionsliste als Kommunikationsfunktionen und als Dienstleistung im LV festzulegen.

5.4.2 Gemeinsame, systemweit genutzte Datenpunkte (Unsubscribed COV Notifications) Mit den Übertragungsverfahren bei Änderung ohne Abonnementauftrag (UnconfirmedCOVNotification) können Informationen über Wert- und Zustandsänderungen verteilt werden, ohne dass dazu ein Abonnementauftrag vorliegen muss. Dieser Mechanismus ist dazu gedacht, gemeinsam genutzte Daten von übergeordneter Bedeutung zu verteilen. Dies sind z. B. die Aussentemperatur oder eine Information aus der der Belegungszustand eines Gebäudes hervorgeht. - Im LV wird die Forderung durch die Zuordnung der GA-Funktion Kommunikative Ein-/Ausgabe

und/oder Management-Kommunikation Ein-/Ausgabe Objekttyp zum entsprechenden Datenpunkt in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt.

- ANMERKUNG: Das System, welches kommunikativ die Datenpunktinformationen aufnimmt, hat für diesen Datenpunkt keine physikalischen E/A-Funktionen. Das bereitstellende System benötigt neben den physikalischen E/A-Funktionen auch die GA-Funktion Management-Kommunikation Ein-/Ausgabe Objekttyp.

5.5 Zeitsynchronisierung In einem verteilten System der Gebäudeautomation ist eine synchronisierte Uhrzeit erforderlich. BACnet erreicht die Zeitsynchronisierung in dem ein Computer als Hauptuhr (Time Master) festgelegt wird. Falls sich ein System über mehrere Zeitzonen erstreckt, kann die Verwendung der so genannten "Coordinated Universal Time" (UTC) sinnvoller als die Verwendung der lokalen Uhrzeit sein. - Im LV wird durch eine Textergänzung bei der Standardbeschreibung für das System festgelegt, dass

die Zeitsynchronisierung über das GA-Netzwerk erfolgt. - Bei heterogenen Systemen wird das System mit der Hauptuhr im LV festgelegt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 43

6. GA-Netzwerk Architektur

6.0 GA-Netzwerke BACnet bietet für den Datentransport eine Auswahl an Netzwerk-Arten und die Möglichkeit unterschiedliche Netzwerke miteinander zu verknüpfen. In diesem Abschnitt werden Hilfestellungen für die Entscheidung für oder gegen einzelne Netzwerkoptionen gegeben sowie die Möglichkeiten für Verknüpfungen zwischen den Netzwerken dargestellt. Da für eine systemneutrale Ausschreibung die Wahl des Daten-Transportnetzwerks dem Anbieter zu überlassen ist, hat in dem vorliegenden Dokument (für den Zweck des B.I.G.-EU/VDI-BACnet Planungskurses) dieses Kapitel nur informativen Charakter.

Abbildung 6-1: Beispiel für ein GA-Netzwerk, das aus mehreren Teilnetzen besteht.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 44

6.1 Netzwerk Struktur Der Ausdruck "Netzwerk Architektur" bezieht sich auf die Struktur aus Netzwerksegmenten und Teilnetzen, die zusammen ein GA-Netzwerk bilden. Siehe Abbildung 6-1. In BACnet erhält jedes Netzwerksegment in einem grossen GA-Netzwerk eine eigene Netzwerknummer (network number). Die Zuordnung von Netzwerknummern wird in Abschnitt 6.4 vertieft. Die einfachste Konfiguration ist ein Netzwerk, das aus einem einigen physikalischen Segment besteht und an dem alle Einrichtungen direkt angeschlossen sind. In diesem Fall muss lediglich die Art des LAN (Local Area Network) ausgewählt werden. Dies wird in Abschnitt 6.2 weiter erläutert. Für jedes LAN ist eine maximale Länge spezifiziert. Daher müssen einzelne physikalische Segmente über Repeater und/oder Bridges verknüpft werden. Brücken lernen selbstständig, wo im LAN sich die einzelnen Teilnehmer/Knoten befinden. Basierend auf diesem Wissen arbeiten sie selektiv und reichen Daten nur im Bedarfsfalle an anderes Segment weiter. Falls mehrere Netzwerke zusammengeschaltet werden, kommen Router ins Spiel. BACnet Router können Netzwerke gleicher oder auch unterschiedlicher LAN Technologie zusammenfassen. Wichtig dabei ist, dass nicht ein langsameres Netzwerk benutzt wird, um schnellere Netzwerke zusammenzuschalten. Das BACnet Protokoll ist grundsätzlich auf dem gesamten Netzwerk zu verwenden. Die Anbindung an bestehende GA-Netzwerke kann allerdings den Einsatz von Gateways erforderlich machen. Dabei kommt es zwangsläufig zu Leistungsverlusten. Durchsatz und Funktionalität werden negativ beeinflusst – siehe die HAK?sche Mengenlehre der Gebäudeautomation, die für jedes heterogene System Gültigkeit hat. - Im LV wird durch Darstellung einer schematischen Netzwerkstruktur als Beiblatt mit Entfernungsangabe zwischen

den Einrichtungen die Möglichkeit gegeben, das Netzwerk des Anbieters zu spezifizieren und zu kalkulieren. (Siehe Anhang E Beispiel Beiblatt 070-10_GA-Netzwerk.PDF).

- Weiterhin werden durch eine Textergänzung bei der Standardbeschreibung für das Systemnetzwerk die Anforderungen grundsätzlicher Art festgelegt.

- Der Bieter muss auf dem Beiblatt 070-11_Netzwerkkomponenten_Bieterang.xls für Mehrungen und Minderungen die geforderten Angaben zu seinem Netzwerk machen (Muster in Anlage.

- Sind bestehende GA-Netzwerke anzubinden oder zu verbinden, sind die Anforderungen im LV hinreichend zu beschreiben.

TLG: Standardbeschreibungen Kabelsysteme - GA STLB-Bau 10/2003 070 Die Anschlussarbeiten für Kabel und Leitungen beinhalten Ablängen, Einführen, Abdichten, Absetzen, Anklemmen und Zugentlastung sowie Auflegen der Abschirmung. Kennzeichnung durch dauerhafte Beschriftung. Alle Enden werden bis zur endgültigen Beschriftung dauerhaft gekennzeichnet. Bezeichnung nach eigener Struktur und Abstimmung mit dem AG. Einführungen mit Zugentlastung, Knickschutz und Verschraubung, Verschraubungen aus Kunststoff. TLG: Netzwerke - GA STLB-Bau 10/2003 070 TA psch:…. Netzwerk für Automationsfunktionen, abgestimmt auf die Automationseinrichtungen zur Kommunikationsverbindung zwischen den Automationseinrichtungen untereinander, Komponenten DIN EN 50173-1, Klasse D (bis 100 MHz), Netzwerk gemäss Beiblatt, Beiblatt-Nr .0815, GA-Netzwerk. die Entfernungsangaben berücksichtigen die geplanten Kabelwege/Trassen, alle angebotenen Komponenten des Netzwerkes, wie Spleissboxen, Verstärker und Steckverbindungen, Kabelanschluss an Geräten und Gerätesteckern, Schutzschläuche, Steck- und Klemmenmaterial, Dosen und Reservelängen sind im Beiblatt 070-4 dargestellt, Kabel- und Verbindungstechnik Kategorie 6 DIN EN 50173-1, geschirmt, Kabel/Leitung, Normbezeichnung ....................................................... (Bieterangabe) auf Pritschen und Wannen verlegen sowie in Kanäle und Schutzrohre einziehen, einschl. aller erforderlichen Anschlüsse.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 45

6.2 Auswahl der LAN (Local Area Network) Option Da bei Aufstellung des Leistungsverzeichnisses für Gebäudeautomation nach DIN EN ISO 16484. mit dem GAEB STLB 070 das Netzwerk systemneutral beschrieben wird, dienen die folgenden Abschnitte für Spezifikationen mit Netzwerkvorgabe und zur Prüfung von Angeboten. Die grundsätzliche Fähigkeit von BACnet, verschiedene LAN Technologien zu unterstützen, ermöglicht es BACnet auch kommende LAN Technologien zu nutzen. Gleichzeitig wird die Rückwärtskompatibilität zu bereits installierten Systemen gewährleistet. Derzeit sind in der BACnet Norm vier verschiedene LAN-Arten zur Auswahl vorgesehen. Jede hat Vor- aber auch Nachteile. Mit Abbildung 6-2 wird der sich zurzeit darstellende Zusammenhang der LAN-Art mit Geschwindigkeit und Kosten dargestellt. Auch innerhalb einer LAN-Arten können verschiedene Medienarten, Topologien und sogar Übertragungsgeschwindigkeiten zur Auswahl stehen, die wiederum die Kosten für die Implementierung und die Leistungsfähigkeit des Netzwerks beeinflussen. Abschnitte 6.2.1 - 6.2.5 stellen die wichtigsten Merkmale der einzelnen LAN Ausprägungen vor und bieten damit Entscheidungshilfen, wenn es um die Auswahl einer LAN -Art geht.

Abbildung 6-2 Gegenüberstellung Kosten und Leistung für verschiedene BACnet LAN Optionen.

6.2.1 ISO 8802-3, Ethernet ISO 8802-3 ist auch als "Ethernet" bekannt. Dabei handelt es sich um die am meisten verbreitete LAN-Art, hauptsächlich auf Grund der Verbreitung in Büro- und Geschäftsnetzwerken. Es ist die derzeit schnellste Netzwerk-Art, die für BACnet zur Verfügung steht. Die meisten Firmen im Bereich der Gebäudeautomation bieten Ethernet als eine Option an, um ihre leistungsfähigen Automationsstationen oder Controller untereinander und mit Management- oder Bedieneinrichtungen zu verbinden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 46

Die wesentlichen Merkmale des Ethernet nach ISO/IEC 8802-3 sind in der Tabelle 6-1 zusammengefasst:

Geschwin- digkeit kB/s

NPDU1 Größe (Bytes)

Pro

Kontra

10.000 - 100.000

1497 - Internationale Norm - Meist bereits im Gebäude vorhanden - Vielzahl bewährter Medien

(TP, Koax, Fiberoptik, Funk) - Sehr schnell - Einfacher, günstiger PC-Anschluss - Kein spezielles Entwicklungstool - Riesige Produktauswahl für alle

Komponenten - Fallende Kosten

- hohe Kosten, wenn nicht als Infrastruktur vorhanden

- Entfernungsbegrenzungen zu beachten

- Nicht deterministisch (was durch hohe Geschwindigkeit und Netzwerksegmentierung nicht stört)

Tabelle 6-1 Merkmale von ISO 8802-3, Ethernet; 1) NPDU = Network Protocol Data Unit Jede der Medienoptionen weist unterschiedliche Merkmale auf bezüglich Kosten und Längenbeschränkungen. Auch die EMV muss bei Auswahl der Komponenten beachtet werden. - Koaxialkabel weist die niedrigsten Kosten auf, beschränkt jedoch die Bustopologie. - Nichtabgeschirmte, verdrillte Zweidrahtleitung (Unshielded twisted pair - UTP) ist in Europa EMV-technisch problematisch. Sie wird sternförmig konfiguriert und macht den Einsatz eines Sternkopplers (HUB) erforderlich. Dabei handelt es sich um eine sehr robuste Architektur, die maximale Flexibilität in Bezug auf die Anordnung der Einrichtungen ermöglicht. Gleichzeitig bedingt diese Architektur aber mehr Sternkoppler und damit Kosten. - Lichtwellenleiter sind unempfindlich gegen elektromagnetische Störungen und die Längenbegrenzungen fallen weniger ins Gewicht. Gleichzeitig handelt es sich aber hierbei um die teuerste Option. Die verschiedenen Medien können in einem System aber auch gemischt verwendet werden. Das 10Mbit/s Ethernet ist für die Bedürfnisse der (derzeitig) meisten Anwendungen im Bereich der Gebäudeautomation ausreichend. In bestimmten Anwendungsfällen kann allerdings die Verwendung eines zur Verfügung stehenden Fast-Ethernet (100Mbit/s) Stranges für einen Teilbereich des Automationssystems erwünscht sein. In einem solchen Fall können 10Mbit/s Segmente und 100Mbit/s Segmente über geeignete Sternkoppler zusammengeschaltet werden. Ethernet stellt zwar die schnellste LAN Option für BACnet dar, ist aber nicht-deterministisch. Das bedeutet, dass man für die Übertragung einer Nachricht keine genaue Übertragungszeit benennen kann. Das liegt an der Art und Weise, wie der Zugriff auf das Übertragunsgmedium für Ethernet geregelt ist. Danach kann ein Teilnehmer (Device) immer dann eine Nachricht übertragen, wenn er sich zuvor davon überzeugt hat, dass kein anderer Teilnehmer eine Nachricht sendet. Wenn allerdings zwei Teilnehmer zur gleichen Zeit mit der Datenübertragung beginnen, kommt es zur Kollision. Kollisionen werden aber nur in einem Netzwerk mit hoher Belastung zum Problem. Wenn ein Netzwerk fachgerecht ausgelegt wurde und wird die Netzwerklast überwacht wird, können diese Probleme vermieden werden. Fachgerechte Netzwerkauslegung im Zusammenhang mit BACnet kann u. a. bedeuten, dass Netzknoten, die ein hohes Aufkommen an Nachrichten erzeugen, auf unterschiedliche Ethernet Segmente verteilt werden oder dass eine Bridge zwischen den Segmenten eingesetzt wird, die den "lokalen" Netzwerkverkehr isolieren, so dass dieser nicht unnötigerweise andere Segmente und Knoten belastet. Spezifikation von Ethernet Local Area Netzwerken (LANs)

Ein Ethernet LAN wird (derzeit noch) als Backbone Netzwerk verwendet und verbindet Management-Einrichtungen (Workstation, Computer) und übergeordnete Automationseinrichtungen miteinander. Die Auswahlmöglickeit an Netzwerkoptionen lässt es ggf. notwendig erscheinen, für bestimmte Aufgaben akzeptable Optionen festzulegen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 47

- Im LV wird durch eine Textergänzung bei der Standardbeschreibung für das jeweilige GA-Netzwerk

die ggf. geforderte Netzwerk-Art festgelegt, z. B. 10Mbit/s Ethernet oder Fast-Ethernet (100Mbit/s), mit Darstellung im Beiblatt „Netzwerkaufbau“ (siehe Anhang E).

Der Bieter muss mit dem Angebot festlegen, für welche Bereiche (oder Einrichtungen) er welches Übertragungsmedium (Normbezeichnung) zum Einsatz bringt. Wenn Hubs (Sternkoppler) und andere Komponenten benötigt werden, ist deren Anzahl, Art und Anzahl der Ports sowie die Art des Mediums pro Port im vorgesehenen Beiblatt für Bieterangaben aufzuführen.

6.2.2 ANSI/ATA 878.1, ARCNET ARCNET (ANSI/ATA 878.1) ist eine LAN Technologie, die langsamer als Ethernet ist, aber im Gegensatz zu Ethernet ein deterministisches Übertragungsverhalten aufweist. Das bedeutet, dass es möglich ist, die maximale Verzögerungszeit zu bestimmen, bis ein Device in der Lage ist, eine Nachricht auf dem Übertragungsmedium abzusetzen. ARCNET wird von einigen Herstellern als ausreichend leistungsfähiges Netzwerk eingesetzt und verbindet "high-end" Automationsstationen miteinander und mit Workstations. Ethernet (als internationale Norm) hat teilweise ARCNET für diese Art der Anwendungen ersetzt. Die neuste Generation von ARCNET Chips verfügt über eine skalierbare Übertragungsrate und setzt auf der EIA-485 Schnittstellendefinition auf. Diese Option ist gerade dabei, in Nordamerika eine gewisse Popularität im Bereich der Raum- und Zonenregelung zu gewinnen. Die wesentlichen Merkmale von ARCNET nach ATA/ANSI 878.1 sind in der Tabelle 6-2 aufgeführt.

Geschwin- digkeit kB/s

NPDU1 Größe (Bytes)

Pro

Kontra

156 - 7.500

501 - Amerikanische Norm - Deterministisch - Anpassbare Geschwindigkeit - Medienauswahl

(TP, Koax, Fiberoptik) - Schnell - Kein spezielles Entwicklungstool - Gutes Kosten-Nutzen- Verhältnis

- Lieferantenabhängigkeit (Chip, "Single Source")

- Zu teuer für low-end Controller (Einzelraumregler)

- Entfernungsbegrenzungen

Tabelle 6-2 Merkmale von ARCNET Spezifizieren von ARCNET LANs

Wenn ARCNET als LAN im Bereich der Raum- und Zonenregelung zum Einsatz kommen soll, muss das Leistungsverzeichnis die Besonderheiten dieses Netzwerks in Abhängigkeit der vorgesehenen Produkte und der Netzwerkübergänge hinreichend beschreiben.

- Das LV legt fest, welche Einrichtungen im Gebäudeautomationssystem an das ARCNET LAN

angeschlossen werden sollen. - Das LV legt fest, welches Übertragungsmedium zum Einsatz kommen soll. Falls mehrere Medien

benutzt werden sollen, muss festgelegt werden, welches Medium wo verwendet werden soll und welche Einrichtungen wo anzuschliessen sind. Falls Sternkoppler (HUBs) zum Einsatz kommen, soll die Anzahl der Ports (Anschlüsse) und die Medienart für jeden Anschluss festgelegt werden.

- Das LV legt fest, wie ARCNET Adressen zugeordnet werden (vergleiche Abschnitt 6.3.1).

6.2.3 Master-Slave/Token-Passing, MS/TP Das Master-Slave/Token-Passing Protokoll (MS/TP) wurde von der ASHRAE mit dem Ziel entwickelt, die Anforderungen von low-cost Automationsstationen zu erfüllen. MS/TP steht ausschliesslich für BACnet zur

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 48

Verfügung und setzt auf der EIA-485 Schnittstelle auf. MS/TP kann im reinen Master-Slave Modus, mit Token Übergabe zwischen gleichberechtigten Kommunikationspartnern (Peer-to-Peer Token passing Methode) oder in einer Kombination beider Methoden betrieben werden (daher stark verwandt mit Profibus). Aus praktischen Gründen ist die Übertragungsgeschwindigkeit auf 76kbit/s beschränkt. MS/TP bietet eine kostengünstige LAN Option in BACnet. Sie ist für eine Implementierung auf einem handelsüblichen Mikroprozessor gedacht und kommt ohne zusätzliche Beschaltung für die Sicherstellung des Übertragungszeitverhaltens und ohne Transceiver Schnittstellen aus. Die wesentlichen Merkmale von MS/TP nach EIA RS 485 und ISO 16484-5 sind in Tabelle6-3 zusammengefasst.

Geschwin- digkeit kB/s

NPDU1 Größe (Bytes)

Pro

Kontra

9.6 - 78.400

501 - Amerikanische Norm - Low-Cost-Lösung - Auf Einchip- Mikroprozessor möglich - Deterministisch - keine speziellen

Entwicklungswerkzeuge erforderlich

- Ein Medium (EIA-RS 485) - Begrenzte Geschwindigkeit

Tabelle 6-3 Merkmale von MS/TP Spezifizieren von MS/TP LANs

MS/TP LANs werden typischerweise im Bereich der Raum- und Zonenregelung eingesetzt. Sie verbinden auch anwendungsspezifische Steuer- und Regeleinheiten, z. B. für VVS-Geräte, Gebläsekonvektoren oder Kühldeckenregelung.

- Das LV legt fest, welche Einrichtungen im Gebäudeautomationssystem an das MS/TP LAN

angeschlossen werden sollen. - Das LV legt die Übertragungsrate (Baud Rate) und die Zuordnung der ARCNET Adressen fest,

(vergleiche Abschnitt 6.3.1). - Das LV legt ggf. fest, wie der Adressraum zwischen Master- und Slave-Devices aufgeteilt wird (siehe

Abschnitt 6.3.2).

6.2.4 EIA-709.1, LonTalk LonTalk ist das patentgeschützte Transportprotokoll der LonWorks Technologie, die von der Firma Echelon1 entwickelt wurde. LonTalk wurde 2000 in den USA neben EIB/KNX als EIA Standard (Electronics Industry Association, Anmerkung des Übersetzers) für allgemeine Automationsanwendungen übernommen. (In Europa ist LonTalk bis ca. 2004 Teil der europäischen Vor- bzw. Experimentalnorm auf der Feldebene (prENV 13154-2) und auf der Automationsebene eine Option für BACnet. Eine Überarbeitung der EIA-709.1 ist bei CEN als Entwurf für ein CNP (Control Network Protocol) eingebracht. Anmerkung des Übersetzers).

1 Bestimmte Warenzeichen und Produkte werden im Text oder Abbildungen erwähnt um Geräte eindeutig zu beschreiben. Das bedeutet aber keinesfalls, dass es sich dabei um eine Empfehlung des Nationalen Instituts für Standards und Technologie (der USA) oder der Normungsinstitute ISO und CEN bzw des VDI handelt. Es bedeutet auch nicht, dass es sich zwangsläufig um die am besten geeigneten Produkte für eine bestimmte Anwendung handelt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 49

Genau wie bei Ethernet und ARCNET ist das LonTalk Protokoll in einem Chip, dem sogenannten Neuron-Chip implementiert. Echelon bietet mit entsprechenden Transceivern für LonTalk mehrere Medienoptionen. Diese werden für traditionell verkabelte LANs (wie UTP, Koax, Lichtwellenleiter) und auch für drahtlose Kommunikation wie Funk (RF) und Infrarot (IR) am Markt angeboten. LonTalk ermöglicht skalierbare Übertragungsgeschwindigkeiten bis 1,25 Mbit/s. Am unteren Ende der Leistungsskala kann man es mit MS/TP vergleichen; allerdings sind die Hardware und die Installation zusammen mit den Lizenzkosten meistens teurer. Am oberen Ende der Leistungsskala entspricht es der Leistungsfähigkeit von ARCNET (bis zu 150kBit/s). Wenn es um Übertragungsgeschwindigkeiten jenseits der 150 kBit/s geht, ist ARCNET in Bezug auf die Hardwarekosten meistens überlegen. LonTalk ist die einzige der zur Verfügung stehenden BACnet LAN Technologien, die spezielle Entwicklungswerkzeuge benötigt. Diese Werkzeuge sind ausschliesslich von Echelon verfügbar. LonTalk wird oft mit LonMark verwechselt. Diese Begriffe haben wenig miteinander zu tun, ausser dass in beiden Fällen Produkte der Fa. Echelon zum Einsatz kommen. Geräte oder Knoten, die über das LonTalk Protokoll miteinander kommunizieren, sind nicht unbedingt miteinander interoperabel, d. h. in der Lage, miteinander zu funktionieren, ausser sie verwenden LonMark oder BACnet. Dazu bedarf es vieler zusätzlicher Festlegungen (in einem Protokoll), die speziell für die beabsichtigte Anwendung des Gerätes getroffen werden müssen. Die BACnet Anwendungsschicht bietet diese Festlegungen. In BACnet ist LonTalk eine unter mehreren wählbaren stehenden LAN-Arten und wird ausschliesslich dazu benutzt, um BACnet Nachrichten zwischen BACnet-Einrichtungen zu transportieren. LonMark ist ein Markenname für ein ganzes Bündel von Übereinkünften der Herstellergemeinschaft LonMark Interoperability Association, die sich Applikationsfunktionen des LonTalk Protokolls zu Nutze machen, um ein gemeinsames Ziel, nämlich die Interoperabilität von Geräten zu erreichen. Es muss ausdrücklich darauf hingewiesen werden, dass LonMark Produkte nicht mit BACnet kompatibel sind. Um ein LonMark Gerät in einem GA-Netzwerk nach DIN EN ISO 16484-5 (BACnet) zu verwenden, muss ein Gateway wie bei jedem anderen proprietären Protokoll eingesetzt werden, auch wenn das BACnet System LonTalk für den Datentransport benutzt. Die Gateway Problematik wird im Abschnitt 6.8 angesprochen. Die wesentlichen Merkmale des LonTalk nach EIA/CEA 709.1-B (gepl. EN 14908-x) Protokolls sind in Tabelle 6-4 zusammengefasst.

Geschwin- digkeit kB/s

NPDU1 Größe (Bytes)

Pro

Kontra

4,8 - 1.250

228 - Medienvielzahl (TP, Koax, Funk, Infrarot, Fiberoptik)

- Anpassbare Geschwindigkeit -

- Lizenzkosten - Abhängigkeit von einer Firma

(Lizenzen, Transceiver, Tools) - Nicht deterministisch - Entfernungsbegrenzungen - Geschwindigkeitsbegrenzung

bestimmter Medien - Spezielle Entwicklungswerkzeuge - Spezielle Werkzeuge für die Baustelle - Programmgröße der Anwendung auf

"Neuron-Chips" stark limitiert Tabelle 6-4, Merkmale von LonTalk Zwischen BACnet- und LonMark- Systemen bedarf es Gateways mit allen bekannten Nachteilen, um diese interoperabel zu gestalten.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 50

Spezifizieren von LonTalk LANs

LonTalk LANs werden in der Regel verwendet um anwenderspezifische Regler miteinander zu verbinden. Es werden also in der Regel mehrere Regler in einem Automationssystem am LonTalk LAN betrieben.

Das LV muss festlegen: - Welche der Geräte in einem Automationssystem an dem LonTalk LAN betrieben werden sollen, - Welche Medien, welche Übertragungsgeschwindigkeit und welche Topologie verwendet werden

sollen, - Wie die die LonTalk Adressen vergeben werden.

6.2.5 Punkt-zu-Punkt Verbindungen (Point-to-Point - PTP) Das Punkt-zu-Punkt Protokoll eröffnet eine Möglichkeit, einzelne Einrichtungen oder Netzwerke seriell und asynchron miteinander zu verbinden; zum Beispiel durch Wählverbindungen über eine Modemstrecke. Dabei arbeiten diese Modems zu beiden Enden der PTP Verbindung während des Verbindungsaufbaus als "Halb-routers" und sehen nach dem Verbindungsaufbau für andere Teilnehmer in ihrem jeweiligen Netzwerk als Router aus (siehe Abbildung 6-1). Wenn es notwendig wird, auf ein BACnet Netzwerk über analoge Wählverbindungen zuzugreifen, sollte PTP festgelegt werden. - Das LV muss das PTP Protokoll festlegen, wenn ein BACnet LAN über analoge Wählverbindung

kommunizieren soll; - Im LV ist der Schutzmechnismus für die Wählverbindung festzulegen, d. h. Passwort, autom. Rückruf,

etc. Die wesentlichen Merkmale des Punkt-zu-Punkt Protokolls nach EIA RS 232-C sind in Tabelle 6-5 zusammengefasst.

Geschwin- digkeit kB/s

NPDU1 Größe (Bytes)

Pro

Kontra

9.6 - 56 (501) - Einzige Auswahl für Wählverbindungen

- Zugeschnitten auf Punkt-zu-Punkt-Anwendungen

- Angepasst an moderne Modem-Standards (V.32bis, V.42)

- Nur Punkt-zu-Punkt - Begrenzte Geschwindigkeit

Tabelle 6-4, Merkmale von PTP

6.3 Strukturierte Vorgabe von MAC-Adressen Media-Access-Control-Adressen Jedes Device in einem BACnet-System hat eine Media-Access-Control-Adresse (MAC). Die MAC-Adresse ist mit der Netzwerknummer zur einheitlichen Identifikation jeden Gerätes für die Übertragung von Meldungen kombiniert. Dies geschieht ähnlich wie eine Strassenadresse auf einem Brief, kombiniert mit der Stadt- und Bundeslandadresse. Bei der Herstellung eines Kommunikations-Chip für ein Ethernet Netzwerk wird eine einmalige MAC-Adresse zugeordnet. Wenn Ethernet zur Datenübertragung verwendet

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 51

wird, ist eine spezielle Adressenkonfiguration nicht notwendig. Für andere BACnet-LANs gilt: die MAC-Adresse muss speziell für jede Installation konfiguriert werden. In einer Multi-Vendor(Hersteller)-Umgebung ist es wichtig, die Zuordnung von diesen Adressen so zu managen, dass keine Duplikate im gleichen Netzwerk vorkommen. In verschiedenen Netzwerken gibt es keine Probleme mit Duplikaten von MAC-Adressen, so wie es kein Problem ist, wenn z.B. eine Hauptstrasse 123 in verschiedenen Städten existiert. Ein anlagenspezifischer Plan für die Zuordnung von MAC-Adressen, an den sich alle Anwender halten, sollte entwickelt werden. Ein Beispiel, wie so etwas für das entsprechende BACnet-LAN aufgestellt werden kann, wird nachfolgend gezeigt. Die zugeordneten Adressen müssen so dokumentiert werden, dass zukünftige Änderungen im Projekt keine Konflikte hervorrufen. - Die MAC-Adresse und deren Zuordnung so zu spezifizieren, wie sie der Anwender benötigt. - Die Liste der zugeordneten MAC-Adressen ist zu spezifizieren und der Projektdokumentation

beizulegen.

6.3.1 Ethernet MAC-Adressen Bei der Herstellung eines Kommunikations-Chip wird für das Ethernet-Netzwerk eine einheitliche MAC-Adresse zugeordnet. Eine spezielle Adressenkonfiguration ist für BACnet-Devices bei der Verwendung von Ethernet nicht notwendig.

6.3.2 ARCNET MAC-Adresse Die gültige MAC-Adresse für BACnet-Devices bei der Verwendung von ARCNET ist 1-255 (0 ist reserviert für Broadcast-Meldungen). Es sind deshalb maximal 255 ARCNET-Devices im gleichen Netzwerk möglich. Wenn das ARCNET-LAN Teil eines Internet-Netzwerkes ist und zwei oder mehr Netzwerke im gleichen Projekt notwendig sind, dann müssen ein oder mehrere Router eingesetzt werden. Es ist sinnvoll, wenn spezielle Adressen von ARCNET-Routern reserviert werden. Wenn das ARCNET-LAN direkt an ein einziges anderes Netzwerk angeschlossen wird, ist eine Adresse ausreichend. Wenn das ARCNET-LAN ein BACKBONE-Netzwerk ist, wird eine Reihe von Adressen benötigt. Die Verwendung der gleichen Router-Adresse in jedem ARCNET-LAN eines Projektes wird für die Identifikation von Routern bei der Störungssuche einfacher. Die Programmierung von BACnet-Geräten, welche die Router-Adresse wissen müssen, wird dadurch auch einfacher. - Der Projekt-Adressierungsplan sollte eine Adresse oder eine Reihe von Adressen reservieren, welche

für ARCNET-Router verwendet werden können. Für den Fall, wo ein Router pro ARCNET-Netzwerk ausreichend ist, ist die Adresse 255 empfehlenswert. Für andere Fälle, wo mehr als ein Router pro Netzwerk benötigt wird, ist es empfehlenswert, die Adressen mit 255 zu beginnen und rücklaufend zu nummerieren.

Es ist wichtig sicherzustellen, dass gleiche Adressen nicht zufällig vorkommen können, wenn mehr als ein Gerätehersteller Vendor-ARCNET verwendet, welche sich im gleichen Netzwerk befinden oder dieser Fall in der Zukunft vorkommen kann. Ein Weg um dies zu verhindern ist, dass jedem Hersteller eine Reihe von Adressen zugeordnet wird. Jeder Hersteller kann dann innerhalb seiner zugeordneten Adressenreihe seine Adresse zuordnen, kann aber nicht ausserhalb seiner Adressenreihe irgendwelche Adressen irrtümlich verwenden. Alle Adressen müssen gut dokumentiert sein, so dass zukünftige Änderungen gut verwaltet werden können. - Der Projekt-Adressierungsplan sollte Reserven für eine Reihe von Adressen pro Hersteller haben. Es

ist zu empfehlen, dass die Reihe mit der niedrigsten Adresse beginnt, welche nicht zu einer bereits vorher zugeordneten Adresse gehört.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 52

6.3.3 MS/TP MAC-Adresse Die gültige MAC-Adresse für BACnet-Devices, welche MS/TP-Netzwerke verwenden, sind 0-254 (255 ist reserviert für Broadcast-Meldungen). Es sind deshalb maximal 255 MS/TP-Devices im gleichen Netzwerk möglich. Es gibt eine zusätzliche Einschränkung: der Adressenplatz ist in ein Master- und ein Slave-Devices unterteilt. Die Adressen 128-254 sind für Slave-Devices reserviert. Die Adressen von 0-127 können für Master- und Slave-Devices verwendet werden. Der Teil des Adressenplatzes, der aktuell für Master-Devices in einer bestimmten Installation verwendet wird, ist für den Wert des Master-MAX-Property der Geräteobjekte unterteilt. Das MS/TP-LAN wird speziell für die Verwendung von Low-cost DDC-Regelgeräte angewendet, wie z.B. Unitary Controller oder anwendungsspezifische Regelgeräte. Es sollte nicht für BACKBONE-LANs verwendet werden, so dass innerhalb eines Projekts möglichst nur ein Router zu anderen LANs eingesetzt wird. Ein Router muss ein Master sein. Es ist zu empfehlen, dass die MAC-Adresse 0 für den MS/TP-Router reserviert wird. - Der Projekt-Adressierungsplan soll die Adresse 0 für den MS/TP-Router reservieren. Wenn mehrere Hersteller MS/TP-Geräte innerhalb eines Netzwerkes einsetzen, oder dies zukünftig geplant ist, dann muss sichergestellt werden, dass keine Adressenduplikate vorkommen können. Ein Weg dafür ist die Zuordnung von Adressen für jeden Hersteller. Dies bedingt sowohl Master- als auch Slave-Adressenplätze zu reservieren. Jeder Hersteller kann die Adressierung innerhalb seines Bereiches wählen, kann aber nicht in anderen Bereichen wählen. Alle Adressen müssen dokumentiert werden, so dass zukünftige Änderungen und Ergänzungen fehlerfrei möglich sind. - Der Projekt-Adressierungsplan soll eine Reihe von Master- und Slave-Adressen für jeden Hersteller

reservieren, soweit als sinnvoll und benötigt. Es ist zu empfehlen, dass die Adressierung mit der niedrigsten Adresse beginnt, welche keine vorherige Zuordnung erhalten hat.

Der Adressenplatz in der Reihe 0-127 soll für Master- und Slave-Geräte aufgeteilt werden, wie voraussichtlich benötigt. Wenn Max_Master bei Verwendung von BACnet-Diensten geschrieben wird, ist es von Vorteil, wenn die niedrigere Adresse zuerst festgelegt und Max_Master zu der höchsten Adresse konfiguriert wird, welche aktuell verwendet wird, anstatt sofort 127 zu verwenden. Dies gilt auch, wenn kein Adressenplatz für Slave-Geräte verwendet wird. Diese Vorgehensweise reduziert den Zeitaufwand für die Suche von neuen Stationen, welche an das Netzwerk angeschlossen werden und erhöht die verfügbare Bandbreite für normale Kommunikationen. Wenn mehrere Master-Geräte zu einem späteren Zeitpunkt zusätzlich ans Netzwerk angeschlossen werden, wird es notwendig den Wert von Max_Master in jedem Master-Gerät einem Update zu unterziehen.

6.3.4 LonTalk MAC-Adresse Wie Ethernet, werden LonTalk-Neuron-Chips mit einer speziellen Adresse oder Neuron_ID hergestellt. Andere Adressenschemata können verwendet werden, die auf Domain-, Subnet- oder Node- Konfigurationen oder auf Domäne-, Group oder Member-Konfigurationen basieren. Wenn die Neuron_ID als einzige Adresse für diesen Knoten verwendet wird, ist keine zusätzliche Konfiguration notwendig. Wenn eine der anderen Adressierungsschemata verwendet wird, muss der Anwender Vorkehrungen treffen, dass keine Duplizierung von Adressen im GA-Netzwerk vorkommen kann.

6.4 Netzwerknummerierung Ein GA-Netzwerk mit BACnet kann bis zu 65.535 vernetzte Teil-Netzwerke verwalten. Dies ermöglicht eine sehr grosse Flexibilität für die Integration von Systemen in verschiedenen Gebäuden. Die Möglichkeit für die Verbindung unterschiedlicher GA-Netzwerke bringt viele Vorteile für das Energiemanagement mit verschiedenen Energieversorgungen, für die Wartungsunterstützung und die Erfassung von Energieverbrauchsdaten. BACnet benötigt in jedem Netzwerk eines Projekts eine einheitliche Netzwerknummerierung. Dies

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 53

bedeutet, wenn separate Gebäude-Netze verbunden werden, muss die Zuordnung von Netzwerknummern so organisiert werden, dass keine Duplikatnummer vorkommen kann. Ein Gesamtplan für die Zuordnung der Netzwerknummerierung muss geplant und für alle Projektbeteiligten festgelegt werden. - Spezifizierte Netzwerknummern müssen von allen Herstellern in der vom Betreiber zugeordneten Art

verwendet werden. Die empfohlene Art für zugeordnete Netzwerknummern soll erlauben, dass jede Region die gesamte Netzwerknummerierungs-Domain innerhalb der Region verwenden kann. Die Region soll jedem Gebäude eine Reihe von Netzwerknummern zuordnen. Die Personen, welche direkt für ein Gebäude verantwortlich sind, werden diese Nummernreihe in der Art unterteilen, welche für das Gebäude am Besten ist. Die Unterteilung über die Netzwerktechnologie kann über Stockwerke oder über Gebäudeflügel erfolgen. Ein Beispiel macht dies übersichtlich. Stellen Sie sich eine Region mit mehr als 655 Gebäuden vor. Die Netzwerk-Nummer-Domain kann wie folgt unterteilt werden:

BBBFF BBB = ist eine Nummer zwischen 1 und 655, zugeordnet zu jedem Gebäude

FF = 00 für das Gebäude-Backbone-Netzwerk FF = 1-35 für die Stockwerksbezeichnung oder für separate Projekte um

Gebäude

Es ist zu Beachten, dass die Netzwerknummer im Bereich BBB = 000 nicht zugeordnet ist. Diese Netzwerknummer soll für spezielle Anwendungen, wie z.B. vorübergehende Telefonverbindungen reserviert bleiben. Wenn eine Region mehr als 655 Gebäude hat oder ein Gebäude mehr als 35 Stockwerke, dann ist es notwendig, die Region zu unterteilen und eine komplette Netzwerknummer-Domain für jede Subregion zu verwenden. Die Konsequenz von separaten Domains ist, dass es nicht möglich ist, Gebäude, die in einer separaten Region sind, ohne die Verwendung von zusätzlichen Mechanismen, welche die Netzwerknummern vereinheitlichen, zu integrieren. Das kann ermöglicht werden, wenn das Zentralmanagement-System BACnet/IP von allen Domänen verwendet wird. Bei der Zuordnung jeder Domäne zu einem getrennten IP-Port ist es möglich, dass zwischen anderen, identischen, unterschieden werden kann. Dies ermöglicht einer Liegenschaft die Kommunikation mit allen Gebäuden, jedes Gebäude kann aber nur mit Geräten innerhalb der gleichen Domaine kommunizieren. Grosse Anwender in USA (GSA) verwalten eine nationale Datenbank von Gebäuden, die ein Nummerierungssystem beinhaltet, welches jede Gebäude identifiziert. Dieses Nummerierungssystem hat einen Bereich der für die BACnet-Netzwerknummerierung zu gross ist. Für jede Region oder Subregion, die eine BACnet-Netzwerk-Domaine hat, muss eine Liste erstellt werden, wo die Gebäudenummer, welche dem Gebäude zugeordnet ist, mit der Reihe von BACnet-Netzwerknummern in Verbindung gebracht wird. Jede Netzwerknummerierungsverwaltung muss garantieren, dass jedes Netzwerk eine einheitlich, den BACnet Voraussetzungen entsprechende Nummer erhält.

6.5 Device-Objekt Adressierung Ein GA-Netzwerk mit BACnet kann bis zu 4.194.305 Teilnehmer (Devices) beinhalten. Diese Einschränkung kommt deshalb zustande, weil jedes Device eine eineindeutige Adresse für das Objekt-Identifizierungsmerkmal des Device-Objekts haben muss. Diese Adressierung ist die Basis für BACnet-Dienste, welche die dynamische Verbindung von Adressen und damit Erfassung von Informationen erlauben. In einer heterogenen (Multi-Vendor) oder Multi-Gebäude-Umgebung muss die Zuordnung von Hardware-Objekt-Identifizierungsmerkmal-Daten so verwaltet werden, dass keine Adresse (Nummer) dupliziert wird.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 54

Eine Struktur für die Zuordnung von Hardware-Objekt-Identifizierungsmerkmal-Daten ist zu planen und allen Projektbeteiligten vorzugeben. - Im LV ist die projektspezifische Abstimmung zur Festlegung der BACnet Hardware-Objekt-

Identifikationsmerkmale (Adressen) vorzugeben. Der empfohlene Weg für die Zuordnung der BACnet Device-Objekt-Identifikationsmerkmale (Adressen) ist die Verwendung von einheitlichen Gebäudenummern, welche auch die Netzwerknummern verwalten (das BBB-Feld ist ein Beispiel dafür). In einem bestimmten Gebäude endet der Objekt-Identifier mit der zugeordneten Gebäudenummer. Der noch verfügbare Identifier-Nummernplatz wird in einer Art unterteilt, welche für das Gebäude typisch sein soll. Ein Beispiel dafür:

XXFFBBB Wobei: XX = ist eine Nummer im Bereich zwischen 00 - 40

FF = 00 für das Gebäude-Backbone-Netzwerk FF = 1-35 für die Stockwerksbezeichnung oder für

separate Projekte innerhalb des Gebäudes BBB = ist eine Nummer zwischen 1 – 655,

jedem Gebäude zugeordnet. Für ARCNET und MS/TP-Netzwerke kann das XX-Feld auch für die Zuordnung von MAC-Adresse (siehe 6.3) benutzt werden. Diese Netzwerk-Managementanwendung hat den Vorteil, dass viele Informationen für die Fehlersuche bei Kommunikationsproblemen zur Verfügung stehen, da die physikalische Ortsbezeichnung vom Hardware-Objekt-Identifikationsmerkmal getrennt werden kann. Dadurch sind viele gültige Objekt-Identifikationsmerkmal-Daten (Objekt-Identifier-Values) nicht verwendbar, weil diese nicht in die Schablone passen. In diesem Beispiel können mindestens 41 Devices in jedem Netzwerk, bei insgesamt 1.476 innerhalb des Gebäudes, präsent sein. Wenn das Gebäude keine 36 Stockwerke (jetzt, und in Zukunft) haben wird, kann der Platz für nichtbenutzte Netzwerke addiert werden, um die Limitierung von 41 Geräten pro Netzwerk zu existierenden Netzwerken zu umgehen. Dies wird für viele Gebäude ausreichend sein, kann jedoch für grosse Gebäude sehr restriktiv sein. Wenn das XX- und FF-Feld in einem Bereich kombiniert wird, der hintereinander Devices für die Installation zuordnet, erhöht sich die Anzahl von möglichen BACnet-Geräten auf 4.195, die unterschiedlichen Netzwerken zugeordnet werden können. Diese Entscheidungen können von Gebäude zu Gebäude entsprechend gemacht werden. Der kritische Faktor ist, dass der Bereich von möglichen Werten einer anderen Gruppe, welche niemals einen Konflikt zu Zuordnung von anderen Gebäuden in der gleichen Netzwerk-Domaine verursacht, restriktiv sein kann.

6.6 Verwendung von BACnet mit Internet-Protokollen BACnet stellt zwei verschiedene Wege für Meldungen zur Verfügung, die über das Internet, unter Verwendung von IP (Internet Protokoll), verschickt werden. Bei dieser Technik können Wide Area BACnet Internet Netzwerke für nationalen oder globalen Datenverkehr erstellt werden.

6.6.1 Tunneling Router BACnet Tunneling Router (BTR) sind Einrichtungen, die wie traditionelle Router funktionieren, für Devices die sich im selben LAN befinden, jedoch IP zur Kommunikation mit peer BTRs bei entfernten LANs benutzen. Dies wird durch die Konfiguration von Routing-Tabellen erreicht, die aus (BACnet-Netzwerk-Nummer, IP-Adresse) Paaren bestehen. Diese Mechanismen sind in Abbildung 6.3 dargestellt. Die Verwendung von BTRs ist relativ preiswert und hat den Vorteil, dass die individuellen BACnet-Devices nicht „IP literat“ sein müssen. Mit anderen Worten, BTRs können mit existierenden BACnet-Netzwerken,

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 55

die auch eine Verbindung zu einem IP-Internet, Intranet oder Internet mit einem Grossbuchstaben „I“ haben, verwendet werden.

Abb. 6-3. Eine Verbindung, welche Annex H Tunneling Router verwendet

6.6.2 BACnet/IP Im Fall von BACnet/IP muss das individuelle BACnet-Device IP-fähig sein. In diesem Fall werden keine Tunneling-Router benötigt und die Devices können untereinander direkt kommunizieren. Zum Versenden von Broadcast-Meldungen von einem IP-Subnetz zu einem anderen spezifiziert BACnet/IP die Verwendung eines Gerätes „BACnet Broadcast Management Device“ (BBMD), weil die meisten IP-Router Broadcast-Meldungen nicht weiterleiten. Ein BBMD arbeitet ähnlich wie ein BTR, aber nur für Broadcast-Meldungen. BACnet/IP spezifiziert auch, wie ein IP-Multicasting angewendet werden kann, um Broadcast zu verbreiten, wenn der IP-Router es unterstützt. Multicasting eliminiert die Verwendung von BBMDS. (Siehe Abb. 6-4).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 56

Abb. 6-4. BACnet/IP-Devices kommunizieren direkt miteinander.

Beachten Sie in Abb. 6-4, dass die A und B Devices im gleichen Netzwerk sind, auch wenn sie sich in verschiedenen IP-Subnetzen befinden. Diese mehrfachen IP-Subnetze können zu einem einzigen BACnet-Netzwerk kombiniert werden. BACnet/IP erlaubt auch „fremden Devices“, z.B. Einrichtungen, die sich nicht im gleichen Subnetz mit anderen BACnet-Geräten befinden, sich an das Internet anzukoppeln. Diese Möglichkeit ist für Bedien- und Managementeinrichtungen vorteilhaft, die Internet-Zugang haben und abgesetzt vom Ort der BACnet-Devices aufgestellt sind - Spezifizieren Sie, ob vorhandene BACnet-Devices ohne IP über ein IP-Netzwerk vernetzt werden,

welches BACnet Tunneling Router gemäss ANNEX H (ISO 16484-5) verwenden sollen. - Spezifizieren Sie, bei neuen Netzwerken die IP verwenden, dass die Devices BACnet/IP nach

ANNEX J (ISO 16484-5) unterstützen. Für die Verteilung von Broadcast-Meldungen müssen in BACnet/IP Netzwerken BBMDs (BACnet-Broadcast-Management-Device) verfügbar sein, ebenso müssen entsprechende Vorkehrungen für die Anwendung von IP-Multicasting getroffen werden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 57

6.7 Routervernetzung von mehreren BACnet-Netzwerken Router bei BACnet werden für 2 spezifische Anwendungen verwendet. Die erste Möglichkeit ist die Verbindung von mehreren Netzwerken, welche unterschiedliche LAN-Arten haben, z.B. ein BACnet-Ethernet-LAN mit einem BACnet MS/TP LAN. Die zweite Anwendung ist für die Verbindung von mehreren Netzwerken, welche die gleiche Technologie verwenden, aber die verfügbaren MAC-Adressen überschritten werden. Ein entsprechendes Beispiel ist ein Router, der zwei ARCNET-LANs verbindet, wobei jedes maximal 255 Devices haben kann. - Es ist zu spezifizieren, dass es in der Verantwortung des Auftragnehmers liegt, jeden Router so zu

konfigurieren, dass das Netzwerknummerierungs-Schema erfüllt wird, welches für dieses Projekt festgelegt wurde.

- Es ist zu spezifizieren, dass jeder Router so konfiguriert ist, dass alle Netzwerk-Schicht-Fehlermeldungen zu bestimmten Bedienstationen gesendet werden, unter Verwendung der BACnet-ConfirmedTextMessage-Dienste

- Es ist zu spezifizieren, dass es die Verantwortung des Errichters ist, dass zu Beginn jeder Router mit Routing-Tabellen konfiguriert wird, die Teil des Projekt-Internets sind.

- Es ist zu spezifizieren, dass der Router in der Lage sein muss, Meldungen an jedem Port und in jeder Länge, die gültig für die verwendete LAN-Technologie ist, empfangen zu können, am Port angeschlossen sein muss und Meldungen zu jedem direkt angeschlossenen Netzwerk, welches Meldungen dieser Grösse weiterleiten kann, versendet.

6.8 Datensatz-Segmentierung Die meisten üblichen BACnet-Meldungen sind zwar kurz, jedoch ist es möglich, dass längere Datensätze ausgetauscht werden, z.B. bei Upload und Download von Gerätedaten und Programmen. Da die Hersteller unterschiedlich eingeschränkte Meldungs-Buffer-Grössen verwenden (zur Optimierung von Speicherkapazitäten), kann notwendig sein, dass Datensatzsegmentierung unterstützt werden muss, um den Austausch von langen Datensätzen zu ermöglichen. Manche LAN-Arten schränken Datensatzlängen ein. Eine einheitliche Struktur bei Meldungslängen und Segmentierungen wird benötigt, um sicherzustellen, dass heterogene Systeme interoperabel sind. - Es ist zu spezifizieren, dass alle BACnet-Einrichtungen den Empfang und die Übertragung von

Meldungen/Datensätzen bis zur längsten Datensatzlänge unterstützen, welche die festgelegte LAN-Art zulässt, oder dass segmentierte Datensätze möglich sind.

6.9 Gateway-Anschluss zu proprietären Systemen In manchen Sanierungsprojekten ist es unwirtschaftlich, dass das gesamte GA- oder GLT- System bei Erweiterung ausgetauscht wird. Mit sogenannten Gateways ist es möglich, vorhandene, proprietäre Systeme in das neue BACnet-System zu integrieren. Ein Gateway ist eine Einrichtung oder Software, die zwischen GA-Systemen mit BACnet und proprietären Systemen mit eigenen, herstellerspezifischen Kommunikationsprotokollen übersetzt. Computer benötigen genaue, konsequent und eindeutig definierte Regeln für die Kommunikation und Interpretation der Daten. Protokoll- und Sprachübersetzungen in Gateways sind meist unvollkommen. Es ist schwierig oder sogar unmöglich alle Eigenheiten, Merkmale, Konzepte, die bei der Programmierung von komplexen Systemen (wie GA-Systeme) von einem System auf ein anderes zu übersetzen. Hinzu kommen die projektspezifischen Festlegungen, Programmierungen und Parametrierungen. Gateways stellen meistens nur den Zugang zu einem Teil der in nicht BACnet Systemen verfügbaren Informationen zur Verfügung. Komplexe Anwendungen, wie Energieoptimierung, Zeitprogramme und Alarmverteilung sind meist überhaupt nicht möglich. Aus diesen Gründen sollten Gateways soweit möglich nicht

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 58

angewendet werden. Sollten Gateways unumgänglich sein, müssen alle Funktionen und Leistungen eindeutig festgelegt werden. Welche Einrichtungen können miteinander kommunizieren?

Gateways sind nicht als Ersatz für eine peer-to-peer Kommunikation bei Automationsfunktionen geeignet. Gateways ermöglichen Bedienen und Beobachten mit Automationseinrichtungen an ein BACnet-LAN und einem Nicht-BACnet-LAN.

- Im LV ist festzulegen, welche Einrichtungen in den unterschiedlichen Systemen über ein Gateway

kommunizieren sollen uns welche Funktionen der gemeinsamen Datenpunkte übertragen werden. Uni-direktionale oder bidirektionale Kommunikation?

Gateways können uni-direktional kommunizieren, womit gemeint ist, dass BACnet-Einrichtungen Zugriff auf Informationen von Nicht-BACnet-Einrichtungen haben, Nicht-BACnet-Einrichtungen jedoch haben keinen Zugriff auf Informationen von BACnet-Einrichtungen. Es ist auch möglich, dass eine Nicht-BACnet-Einrichtung auf Informationen von BACnet-Einrichtungen zugreifen kann, aber BACnet-Einrichtungen keinen Zugriff auf Informationen von Nicht-BACnet-Einrichtungen. Gateways können auch bidirektional kommunizieren.

- Im LV ist festzulegen, welchen Weg Informationen über einen Gateway nehmen sollen, bidirektional bzw. uni-direktional.

Welche Datenpunkte müssen lesbar und änderbar sein?

Gateways haben eine limitierte Kapazität. Nicht alle Informationen, die in einem Projekt verfügbar sind, sind in einem Gateway zugriffsfähig.

- Im LV wird die Forderung durch die Zuordnung der GA-Funktionen Ein-/Ausgabe- und komplexe

Objekttyp zum Datenpunkt in der GA-Funktionsliste dokumentiert und mit der entsprechenden LV-Position festgelegt.

Erweiterungen - Im LV wird durch eine Textergänzung bei der Standardbeschreibung für das Gateway-System

festgelegt, wie viele Datenpunkte im Endausbau übertragen werden können. Archivierung von Systemkonfigurationsdaten und von historisierten Daten

Viele GA-Systeme stellen Einrichtungen für die Archivierung von Programmen und Daten mittels Upload der entsprechenden Dateien von der Automationseinrichtung zur Verfügung. Diese Archivierung wird auch für Wiederherstellung der letzten Konfiguration im Falle von Systemstörungen verwendet. Gateways sind möglicherweise nicht in der Lage diese Informationen zu übertragen.

- Im LV wird die Art und Weise der Archivierung mit Backup und Restore Funktionen festgelegt.

Trends

Die Erfassung von Trenddaten wird bei proprietären GA-Systemen unterschiedlich durchgeführt. Ein Gateway kann zulassen, dass eine Bedien- oder Managementeinrichtung Zugang zu Datenpunkten für eine Trend-Aufzeichnung hat, möglicherweise kann es aber Trend-Log-Daten, die von einer

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 59

Automationseinrichtung erstellt werden, nicht übertragen. Es ist wichtig zu verstehen, welche Trend-Aufzeichnungs-Fähigkeiten ein proprietäres System hat, und dass das Gateway die notwendigen Funktionen für die Trend-Aufzeichnung unterstützt. Für zusätzliche Informationen über Trend-Aufzeichnung siehe auch 3.4 und die DIN EN ISO 16484-3.

- Im LV werden die Art und Weise der Trend-Aufzeichnung und die dafür vorgesehenen Datenpunkte

festgelegt. Zeitprogramme

Zeitprogramme werden von den verschiedenen proprietären GA-Systemen auf unterschiedliche weise durchgeführt. Wenn Zeitprogramme gefordert werden, welche über das Gateway zu übertragen sind, muss diese Möglichkeit und deren Funktion genau beschrieben werden. Für weitere Informationen über Zeitprogramme siehe 3.3 und die DIN EN ISO 16484-3.

- Im LV werden die Art und Weise der Zeit-Programm-Übertragung und die dafür vorgesehenen

Datenpunkte festgelegt.

Alarm- und Ereignisbehandlung

Die Erfassung, Erkennung und Quittierung von Alarmen und anderen Ereignissen werden in proprietären GA-Systemen unterschiedlich gehandhabt. Es ist notwendig zu verstehen, welche Alarm- und Ereignisbehandlungsmöglichkeiten ein proprietäres System hat, und dass das Gateway die notwendigen Funktionen für die benötigte Alarm- und Ereignisverarbeitung unterstützt, die in einem integrierten System verlangt werden. Für Weitere Informationen über Alarm. und Ereignisbehandlung siehe DIN EN ISO 16484-3.

- Im LV werden die Art und Weise Ereignis– und Alarmbehandlung und die dafür vorgesehenen

Datenpunkte festgelegt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 60

7. Hinweise für die Planung und Ausführung von BACnet Systemen

7.0 Allgemeines Die erfolgreiche Planung, Ausführung und Betrieb eines BACnet Gebäudeautomationssystems wird direkt von verschiedenen Punkten beeinflusst. Diese Punkte können in Abhängigkeit der Projektphasen eines jeden Projektes dargestellt werden. Von der Planung über die Vergabe bis hin zum Betreiben und der Wartung. In den folgenden Abschnitten, sollen einige generelle Richtlinien und Empfehlungen für die Planungs-, Vergabe-, Inbetriebnahme- und Betriebs-/Wartungsphase eines Gebäudeautomationsprojektes gegeben werden.

7.1 Planung und Vergabe Ein erfolgreiches Projekt benötigt eine sorgfältige Ausschreibungsphase mit Vergabe an einen oder mehrerer Hersteller/Errichter. Die Vergabeunterlagen richten sich nach der VOB. Ein kompletter Satz der Dokumentation der Ausführungsplanung muss mit dem Leistungsverzeichnis den Anbietern zur Verfügung stehen. Diese umfassen u. A. die GA-Funktionslisten nach DIN EN ISO 16484-3 (bzw. VDI 3814-1:2004) die vorgegebenen Beiblätter für Adressierung, Netzwerk- und Systemstruktur, ggf. IP-Adressierung, Angaben zur Interoperabilität bei geplanten heterogenen Systemen, Beiblätter für Bieterangaben. Die Projektbeschreibung im Leistungsverzeichnis gibt dem Bieter einen Überblick über das Projekt. Die vom Bieter ausgefüllten Beiblätter mit PICS und BIBBs geben dem Planer die Möglichkeit verschiedene Gebäudeautomationsprodukte verschiedener Hersteller untereinander zu bewerten. Hier müssen alle geforderten Angaben enthalten sein, die zur Sicherstellung der Interoperabilität bewertet werden. Dadurch werden Missverständnisse und Probleme bei der Ausführung des Projekts vermieden. Wenn die Projekterfordernisse ein System mit Produkten unterschiedlicher Herstellern verlangen, muss im Leistungsverzeichnis auf eine klare und eindeutige Definition der Liefergrenzen geachtet werden. Für die Zuordnung der Engineering- Dienstleistungen bei gemeinsamen Datenpunkten sind die Funktionslisten nach DIN EN ISO 16484-3 besonders geeignet. Damit lassen sich Überschneidungen bei Systemkomponenten (Hard- und Software sowie Dienstleistungen) vermeiden. Jedes Angebot muss eine Beschreibung des vom Bieter angebotenen Systems enthalten. Aus der Beschreibung müssen die Systemarchitektur und die zu implementierende Funktionalität hervorgehen. - Da jedes LV grundsätzlich anzuerkennen ist, darf als Nebenangebot oder als Begleitschreiben eine

Beschreibung der Abweichung von der techn. Spezifikation im Leistungsverzeichnis mitgegeben werden.

Die dem Angebot beigefügte Systembeschreibung umfasst: - Ein Überblick über das Gebäudeautomationssystem, Automationseinrichtungen/Controller,

Bedieneinrichtungen und die Netzwerk-Topologie des Systems. - Beiblatt mit Aufstellung der Massen der angebotenen Hardwarekomponenten (z.B. je

Informationsschwerpunkt, für Nachweis der Reserven und für Mehrungen und Minderungen) und die entsprechenden Datenblätter.

- Referenzliste von vergleichbaren Projekten - Möglichkeit der Präsentation des Systems beim Hersteller

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 61

Je nach Anforderungen des Bauherrn ist eine Bieterselbstauskunft mit Anzahl der Mitarbeiter, Niederlassungen und lokalen Referenzen mit BACnet dem Angebot beizufügen. Mit den o.g. Informationen kann der Beratende Ingenieur sicherstellen, dass der Anbieter die Projektaufgabe verstanden hat, entsprechende Erfahrung besitzt und ein System angeboten hat, welches der Ausschreibung entspricht. Wenn abweichende Alternativen angeboten wurden kann überprüft werden ob diese aufgrund der Projektanforderungen akzeptiert bzw. abgelehnt werden müssen. Die BACnet-Anforderungen der technischen Spezifikationen und die Zertifizierungsunterlagen dienen als Prüfkriterium. Die Informationen die durch das PICS und die BIBBs zur Verfügung gestellt werden sind mit der techn. Spezifikation zu vergleichen, um sicherzustellen, dass das die Produkte die bei der Planung vorgegebene Funktion im Gesamtsystem erfüllen. Erweiterung eines vorhandenen BACnet-Systems Wenn bei einem Projekt ein vorhandenes BACnet-GA-System durch einen anderen Hersteller erweitert wird, ist der zweite Hersteller detailliert über das vorhandene System zu informieren und eine Koordination/Abstimmung mit dem ersten Hersteller ist zu ermöglichen. Es ist sehr wichtig, einen Ansprechpartner zu haben, der die Systemkonfiguration und Funktionalität der vorhandenen Anlagen und des Erstsystems über die zu übergebende Dokumentation hinaus gut kennt.

7.2 Montageplanung Zu Beginn der Systemprojektierung müssen die für eine Interoperabilität erforderlichen Dokumente auf Basis der zu errichtenden Anlage erstellt werden. Hierzu gehören die Automationsschemata der real gebauten Anlagen, Funktionsbeschreibungen, die ISO GA-Funktionslisten dazu, sowie die PICS und BIBBs der eingesetzten Produkte. Bei der Abstimmung bzw. Koordination zwischen dem Bauherren, dem Planer und den Auftragnehmern sind weitere spezielle Betrachtungen z. B zur Betriebsführung erforderlich.

7.2.1 Protocol Implementation Conformance Statements (PICS) Als Teil der Unterlagen des Auftragnehmers sind das PICS und die BIBBs für jede im System eingesetzte Einrichtung (Station/Gerät) zu übergeben. Alle nach der Norm DIN EN ISO 16484-5 und nach LV geforderten Daten sind für die Koordination bereitzustellen: 1. Unterstützte BACnet Dienste.

Tabellarisch werden die durch das jeweilige Device unterstützten BACnet Dienste dargestellt. Siehe Anhang A für die ausführliche Beschreibungen dieser Dienste;

2. Unterstützte Standard Objekt-Typen. Diese Tabelle zeigt die unterstützten Objekttypen wie in Kapitel 4.2 aufgeführt. Sie zeigt auch inwieweit Objekte dynamisch erstellt oder/und gelöscht werden können, und weitere optional unterstütze Objekt-Properties sowie überschreibbare Properties.

3. Data Link Layer Optionen. Hier werden die für die Kommunikation unterstützten Netzwerk-Arten beschrieben z.B. Ethernet/IP, Arcnet, LonTalk oder MS/TP.

4. Spezielle Funktionalitäten. Hier werden alle speziellen Ausnahmen beschrieben, welche eine Einrichtung gegenüber dem BACnet-Protokoll für spezifische Funktionen hat.

5. Property-Bereichseinschränkungen. Hier werden die zugelassene Zahl der Zeichen, der für das Projekt vorgesehene Zeichensatz, und die Inhalte von Text-Properties, wie „Object_Name“ und Objekt-Beschreibung („Description“) festgelegt.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 62

7.2.2 GA-Funktionslisten Die Auftragnehmer haben basierend auf den Funktionslisten der Ausführungsplanung (im LV) und den Datenpunktlisten nach Festlegung der Feldgeräte die endgültigen GA-Funktionslisten nach DIN EN ISO 16484-3 für ihr System zu erstellen und der Bauleitung zur Prüfung/Koordination vorzulegen. Mehrungen und Minderungen, bedingt durch geänderte Anlagentechnik, können hier bereits dokumentiert werden. Um BACnet-Interoperabilität sicherzustellen, müssen die folgenden Informationen enthalten sein: - Die aus dem vorgegebenen Adressierungsschema erstellte endgültige Datenpunktadressierung. - Der Datenpunkt- Adressschlüssel sollte in der technischen Spezifikation (LV) enthalten sein. Ist dies

nicht der Fall, so ist die Konzeption des Adressierungssystems als „besondere Leistung“ an eine Errichterfirma zu beauftragen (VOB/GAEB).

- Die Funktionszuordnung bei gemeinsamen Datenpunkten in einer zugeordneten GA-Funktionsliste je Auftragnehmer.

- Alle beteiligten Auftragnehmer haben diese GA-Funktionslisten verbindlich abzuzeichnen. - BACnet Objekt-Beschreibungen enthalten die Objekt ID und die (Hardware) Device ID für jeden

Datenpunkt. In einem heterogenen System mit mehreren Herstellern sollte hier besondere Sorgfalt angewendet werden, um sicherzugehen, dass keine Device ID´s doppelt vorhanden sind. Auch Nicht-Standard BACnet-Objekte und –Properties sollten einschliesslich ihrer Struktur- und Datenarten dokumentiert sein.

7.2.3 Koordination und Verantwortung Voraussetzung für ein erfolgreiches Projekt ist, insbesondere bei Systemintegration, dass ein Projektbeteiligter die Verantwortung für die Integration der unterschiedlichen Systeme übertragen bekommt. Da in der Regel die Systemhersteller untereinander kein Vertragsverhältnis haben, kann die Zusammenarbeit nur in Form der baustellenüblichen Koordinationspflicht (nach VOB) gemeinsam mit der Bauleitung erfolgen. Die Gesamtverantwortung für die Funktion des neu entstehenden Gesamtsystems (auch nach dem Produktsicherheitsgesetz) bleibt in diesem Falle grundsätzlich beim Bauherrn oder seinem Vertreter. Eine erfolgreiche BACnet Interoperabilität bei einem heterogenen System hängt von der Zusammenarbeit zwischen den beteiligten Herstellern oder Errichtern, den weiteren Auftragnehmern der TGA und dem Kunden, bzw. seinen Vertretern, ab. Um diesen Prozess effektiv sicherzustellen, muss der für die Systemintegration verantwortliche Auftragnehmer oder die Bauleitung eine Übersichts- und Aktivitätenliste (als Bauablaufplan) erstellen, die alle BACnet notwendigen Informationen und Anforderungen auflistet: z. B. beteiligte Hersteller/Errichter, TGA-Schnittstellen, LAN/WAN-Koordination. Diese Liste enthält alle Kontaktadressen der beteiligten Firmen, Kontaktpersonen des Bauherrn und kritische Termine, sie wird regelmässig gemeinsam mit allen Projektbeteiligten durchgesprochen und aktualisiert.

7.3 Protokollanalysator und Inbetriebnahme Während der Inbetriebnahmephase ist jede Funktion (z. B. Regelsequenz) zusammen mit den Bedienfunktionen einschliesslich der Alarme, Graphiken, Berichte, Trend-Aufzeichnungen, Historisierungen u.s.w. zu überprüfen. Dabei wird auch das Funktionieren der BACnet-Kommunikation überprüft. Es ist sinnvoll einen Protokollanalysator zu benutzen. Damit kann der Datenfluss und der Dateninhalt betrachtet werden. Ein Protokollanalysator ist eine Software auf einem Computer, der Daten auf dem Netzwerk „mithört“, deren Inhalt interpretiert und in einem einfach zu verstehenden Format darstellt. Die Kenntnis des BACnet-Protokolls ist eine Vorbedingung zur Interpretation des erfassten Netzwerkverkehrs. BACnet-Protokollanalysatoren sind von der B.I.G.-EU in Form einer Visuellen-Test-Oberflächen-Software verfügbar. Die Analysatorsoftware kann je nach Projekterfordernis auf einen Notebook oder auf einem PC installiert werden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 63

Mit einem Protokollanalysator kann geprüft werden, ob Alarme an die korrekten Empfänger adressiert sind; COV-Mitteilungen richtig erzeugt werden; ob Zeitsynchronisierungen in korrekten Abständen gesendet werden usw. Für spezielle Probleme kann der Protokollanalysator auf einen bestimmten Trigger eingestellt werden, so dass seine Datenerfassung auf eine spezifische Meldung, ein Quellgerät, Zielgerät, eine Zeit oder einen anderen definierten Zustand eingestellt wird. Ebenso können die erfassten Daten gefiltert werden, um nicht relevante Meldungen herauszufiltern. Die Erfahrung hat gezeigt, dass die meisten Funktionsprobleme mit einer falschen Konfiguration oder mit Programmierfehlern in Verbindung stehen. In solchen Fällen kann durch die Nutzung eines Protokollanalysators häufig die Ursache des Problems innerhalb kurzer Zeit festgestellt werden. In heterogenen Projekten ist aus rechtlichen Gründen, insbesondere wegen der Zuordnung der Schadensanteile im Schadenfalle, dringend geboten, einen Protokollanalysator mit Speicherfähigkeit fest zu installieren. Diese kann Bestandteil des Titels „GA-Netzwerk“ im LV sein.

7.4 Dokumentation und Schulung

7.4.1 Dokumentation Vor der endgültigen Abnahme sollte der Betreiber in Besitz der kompletten Dokumentation sein. Sie umfasst für BACnet-Systeme folgende Bestandteile: - Bestandspläne – gemäss DIN 18386, Schemata und Pläne die das Gesamtsystem in den

erforderlichen Details dokumentieren z.B. Netzwerktopologien und die Systemarchitektur mit Konfigurationsdaten.

- Datenpunktlisten mit Datenpunktnamen (-adressen), Einheiten, Grenzwerten, Objekt-Beschreibungen, Objekt-ID und Device-ID für jeden Datenpunkt.

- Funktionslisten mit eingetragenen, umgesetzten Funktionen – auch für die Abrechnung, - Dokumentation der Nicht-Standard BACnet Objekte;

Für jeden Nicht-Standard BACnet-Objekttyp incl. Properties, Benennungen, Strukturen und mit allen Parametern.

- Programmdokumentation je nach verwendeter Programmiermethode, z. B. Programmablaufpläne, kommentierte Programmlistings.

- Datensicherung der aktuellen Source-Codes aller DDC-Programme (Automationsprogramme) Wenn Hardware und oder Software-Änderungen durchgeführt werden, müssen die Dokumentationen aktualisiert werden, damit immer die aktuellen Strukturen und Betriebsparameter des Systems vorliegen. Damit kann bei zukünftigen Erweiterungen der Systemverantwortliche auch bei anderen Herstellern die Gesamtfunktionalität des Systems incl. der Erweiterung sicherstellen. Erfahrungsgemäss verliert ein Gesamtsystem sehr schnell seinen Nutzwert, wenn Änderungen/Erweiterungen z.B. der Anlagenautomation, auf Bedien- und Managementeinrichtungen nicht nachvollzogen werden. Es gibt genau deshalb sehr viele verwaiste „Leitsysteme“, mit der Folge eines hohen Personalaufwands bei Verzicht auf effizientes Energiemanagement.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 64

7.4.2 Schulung Die Betreiberausbildung ist ein wesentlicher Bestandteil der GA-Systemanwendung – nicht nur bei BACnet-Projekten, hier jedoch besonders. Die Trainingsanforderungen werden im Leistungsverzeichnis spezifiziert, so dass das Betriebspersonal ein komplettes Systemtraining erhält und in der Lage ist das System komplett zu betreiben und zu warten. Eine solche Ausbildung kann dazu dienen die Betriebskosten zu senken, da das Bedienpersonal in der Lage ist, kleinere Erweiterungen selbständig auszuführen und das System optimal zu Betreiben. Die folgenden Punkte sind zu berücksichtigen: - Eine Systemeinweisung vor Ort (VOB DIN 18386) ist grundsätzlicher Bestandteil der Lieferungen und

Leistungen - Eine Schulung im Werk des Herstellers ist als besondere Leistung im LV festzulegen,

dabei ist die Mindestanzahl der Tage für das Training durch den Hersteller und die Anzahl des zu schulenden Bedienpersonals zu spezifizieren.

- Der minimale Kursinhalt wird im LV beschrieben. Zusätzlich zur Grundausbildung sollte die Schulung einen Überblick über das BACnet-Protokoll- und die Netzwerke umfassen. Der Bediener sollte nach der Schulung in der Lage sein, Datenpunkte hinzuzufügen, zu löschen und/oder zu ändern, Berichte/Reports und Bilder an Bedien- oder Managementeinrichtungen zu erstellen oder zu bearbeiten.

Der Leiter der Betriebsführung (Facility Manager) und/oder sein Vertreter sollten am Training teilnehmen, um die Möglichkeiten des GA-Systems kennen zu lernen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 65

8. Rechtliche Bewertung öffentlicher Ausschreibungen

8.1 Rechtliche Aspekte in Bezug auf die VOB Bei zu mindestens 50% öffentlich finanzierten Projekten gilt VOB/A für die Vergabe, die VOB/B für das Kaufmännische und VOB/C DIN 18299 (allgem.) und DIN 18386 (GA) für das Technische. Die VOB wird von Richtern auch dann herangezogen, wenn diese nicht direkt vereinbart wurde, – sie repräsentiert den „allgemein anerkannten Stand der Technik“ und als Ergänzung des BGB – Werkvertrags für die Besonderheiten im Bauwesen, ist sie die „Rückfallposition“ der Richter. Und zwar dann, wenn der ursprüngliche „Vertrag“ dazu führte, dass man „sich nicht verträgt“. Auch ein GU muss seinen Subunternehmer und der Sub seinen SubSub nach VOB beauftragen, wenn es ein VOB-Projekt ist. Nebenabreden und der VOB widersprechende Vertragsklauseln sind von Anfang an ungültig. (das gilt natürlich auch für einen GA-Sub als Systemintegrator).

8.2 Besonderheiten in Bezug auf spezielle Produkte oder "Technologien" Zum Beispiel: Gefordert sind „reine LON-Systeme“ Die LON-Technologie findet relativ breiten Einsatz in Deutschland. Gefördert von der LNO und im speziellen vom Arbeitskreis Systemintegratoren der LNO, werden immer mehr „reine LON-Systeme“ gefordert, und diese In vielen Fällen stellt sich die Situation für den Markt wie folgt dar: Die Forderung nach speziellen "Lösungen" wird in sogenannte "neutrale" Leistungsverzeichnisse eingebracht – oft so, dass ein Nichtfachmann die "Anforderungen zwischen den Zeilen" nicht erkennen kann. Beispiele sind: - Das Leistungsverzeichnis enthält eine genaue Aufstellung der geforderten Hardwarekomponenten,

(Das STLB-Bau 070 beschreibt die funktionalen Anforderungen, der Bieter muss "seine" Hardwarelösung angeben).

- Forderung einer bestimmten "Netzwerk-Topologie" (nach STLB-Bau kann diese dem Wettbewerb unterzogen werden)

- Die Funktionalität des Systems bezüglich der Automation ist nicht beschrieben. - Die gewerke-, system- oder geräteübergreifenden Funktionen sind nicht eindeutig beschrieben. - Die Interoperabilität bei heterogenen Systemen ist nicht beschrieben. - Es ist nicht beschrieben für welche Bereiche oder Anwendungen eine Interoperabilität mit ggf. anderen

Systemen gefordert wird, - Ein "auditierter Systemintegrator" wird gefordert bzw. wird gestellt, die Systemintegratorenleistung ist

allerdings nicht oder widersprüchlich beschrieben. - Es werden "schwammige", nicht genormte Begriffe verwendet. Eine Ausschreibung/Vergabe mit solchen oder vergleichbaren Inhalten ist daher grundsätzlich anfechtbar! Projekte mit Systemintegration Gerade bei Projekten mit Systemintegration ist es wichtig, dass der wesentliche Teil für die technischen Dienstleistungen – mit den GA-Funktionen - so beschrieben ist, wie es die VOB/A §9 verlangt: Abs. 1: Die Leistung ist eindeutig und so erschöpfend zu beschreiben, dass alle Bewerber die Beschreibung im gleichen Sinne verstehen müssen und ihre Preise sicher und ohne umfangreiche Vorarbeiten berechnen können. Es darf kein ungewöhnliches Wagnis aufgebürdet werden. Auskömmliche Preise sind nur nach VOB/C DIN 18386 ermittelbar, denn damit werden Leistung und Preise eindeutig, erschöpfend, sicher und ohne Vorarbeiten ermittelbar.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 66

Anmerkung: Der Teil A der VOB wird nicht Vertragsbestandteil, doch aus seinen Regelungen ergibt sich seit 2000 ein klagbarer Rechtsanspruch für den Anbieter / Bewerber. Beispiel: Ein Leistungsverzeichnis entspricht nicht der VOB/C DIN 18386, wenn die Hardware und die GA-Funktionen als Dienstleistung nicht in getrennten Positionen (z.B. nach STLB-Bau 070) vorgesehen sind.

8.3 Leistungen für Gebäudeautomation nach VOB Die Lieferung und Leistung muss nach VOB/C DIN 18386 Teil 0 ausgeschrieben werden:

VOB Teil C / DIN 18386:2002 „Gebäudeautomation“: 0.5 Abrechnungseinheiten 0.5.2 Abrechnungseinheiten nach Stück 0.5.2.1 Systemkomponenten (Hardware) 0.5.2.2 GA-Funktionen (Software) und Dienstleistungen, getrennt nach Art und Leistungsmerkmalen entsprechend VDI 3814 Blatt 2 für:

o Grundfunktionen (neu nach Norm: Ein-/Ausgabefunktionen) Schalten-Stellen-Melden-Messen-Zählen

o Verarbeitungsfunktionen: Überwachen-Steuern-Regeln-Rechnen/Optimieren o Statistik/Mensch-System-Kommunikation (neu: Bedien- und Managementfunktionen)

(Die VDI 3814-2 wurde ersetzt durch VDI 3814-1:2005 und DIN EN ISO 16484-3:2005).

8.4 VOB/B § 8 und 9, Gründe für die Kündigung des Vertrages Als Kündigungsgründe durch den Auftraggeber gelten:

- Beantragung des Vergleichsverfahrens, Konkurs, - Einstellung von Zahlungen an Dritte, - Abs 4: Wenn der Auftragnehmer aus Anlass der Vergabe eine Abrede getroffen hatte, die

eine unzulässige Wettbewerbsbeschränkung darstellt (innerhalb von 12 Werktagen nach Bekanntwerden).

die Kündigung ist schriftlich zu erklären. Sollte einem GA-Systemerrichter doch einmal passiert sein, einen Auftrag ohne vollständige Beachtung der VOB entgegengenommen zu haben, so kommt er nur nach den Regeln von VOB/B §9, BGB 293 ff, BGB § 642 wieder heraus, z.B.:

- wenn der Auftraggeber den Auftragnehmer ausserstande setzt, die Leistung auszuführen (Annahmeverzug nach §§ 293 ff. BGB),

- wenn der Auftraggeber z. B. eine fällige Zahlung nicht leistet,

Es gibt Fälle bei denen vorsätzliche oder grob fahrlässige falsche Angaben in den Vergabeunterlagen dem Unternehmer ein Kündigungsrecht ermöglichen.

8.5 Anforderungen an ein Leistungsverzeichnises nach VOB/A § 9 Ein LV muss folgende Bedingungen erfüllen (Interpretation nach GAEB):

- technisch richtig - aktuell - vollständig - eindeutig - wettbewerbsneutral - rechtlich abgesichert

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 67

Häufig passiert, dass Fakten erst bei Genehmigung der „Montage und Werkstattplanung“ (VOB) bekannt werden, dann ist für Mehrungen und Nachträge – oder Anfechtung - wichtig, eine eindeutige Vertragsgrundlage zu haben. Die GA-Funktionen im VDI-3814-Standard (DIN EN ISO 16484-3), als LV-Text im STLB-Bau 070 sind dafür vorgesehen. Bei GU-Aufträgen muss man rechtzeitig auf einen Ausschreibungsmangel hinweisen. Wenn hier mit Angebotsabgabe ein offensichtlicher Fehler akzeptiert wird, ist es dann ein schwieriger Fall für Rechtsexperten.

8.6 Aufteilung in Fachlose und Änderung der zu erbringenden Leistung Insbesondere für die GA sind zu beachten: VOB/A §4: Wird die Gesamtleistung nach Fachgebieten ( z.B. Gewerken ) aufgeteilt, handelt es sich um Fachlose; diese können z. B. mehrere bauliche Anlagen einschließen. Sollen Teile einer bestimmten Leistung an mehrere Auftragnehmer vergeben werden, handelt es sich um Teillose, z. B. mehrere Gewerke in einer bestimmten baulichen Anlage. Heterogene GA-Projekte mit BACnet können unter VOB/A §4 fallen. VOB/B § 2: Eine Änderung von Art und Umfang der vertraglich zu erbringenden Leistung ist stets vor Ausführung der Leistung zwischen Auftraggeber und Auftragnehmer zu vereinbaren. Die international anerkannte GA-Funktionsliste ist das beste Dokumentationsmittel für diesen Zweck

8.7 Einzukalkulierende Nebenleistungen VOB/C Abschnitt 4

4.1 Nebenleistungen sind alle Leistungen, die nach - der Leistungsbeschreibung, - den Besonderen Vertragsbedingungen, - den Zusätzlichen Vertragsbedingungen, - den Zusätzlichen Technischen Vertragsbedingungen, - den Allgemeinen Technischen Vertragsbedingungen und - der gewerblichen Verkehrssitte zur vertraglichen Leistung gehören. Sie sind durch die vereinbarten Preise abgegolten. Für GA gilt nur VOB/C DIN 18386!

4.2 Besondere Leistungen sind nur dann durch die vereinbarten Preise abgegolten, wenn sie ausdrücklich in der Leistungsbeschreibung aufgeführt sind. Siehe hierzu DIN 18386, Kapitel 4.2 und das GAEB STLB-Bau 070.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 68

9 Rechtliche Aspekte der Systemintegration

9.1 Einleitung Die Gefahrenmeldetechnik wird zur Sicherheit des Gebäudes, der darin arbeitenden Menschen und den installierten technischen Einrichtungen eingesetzt, und ohne eine gewerkeübergreifende Gebäudeautomation ist eine effiziente Betriebsführung nicht mehr denkbar. Die Gebäudetechnik wäre ohne sie nicht beherrschbar und nicht optimierbar. Bei einer Zusammenschaltung dieser Systeme sind neben den technischen Möglichkeiten auch die rechtlichen Rahmenbedingungen zu betrachten.

9.2 Verantwortung für Sicherheit Mit Hilfe einer Kosten/Nutzenanalyse kann die Gefahrenmelde- und Sicherungstechnik nicht unantastbar als wirtschaftlich belegt werden. Somit muss sich jeder Unternehmer die Frage stellen und beantworten, ob er für sein Unternehmen, seine Kunden und seine Mitarbeiter im Schadensfall ausreichende Vorsorge getroffen hat – sofern ihn gesetzliche Vorgaben nicht dazu zwingen, vor Gefahren zu schützen oder beim Eintritt derartiger zu warnen. In Deutschland ist dies die UVV BGV1 §37, Absatz 1. Gretchenfrage Wer ist nun für die Funktion verantwortlich, wenn unterschiedliche Systeme mittels der Kommunikationstechnik zusammengeschalten werden? Diese Art von Zusammenschaltung wird Systemintegration genannt. Die Antwort wird weiter unten gegeben.

9.3 Verträge und Versicherungen Vertragliche Haftung: Diese entsteht aus Zusicherungen im Bauvertrag (Werkvertrag). Widersprüchen im Bauvertrag entsteht folgende Reihenfolge der Gültigkeit: (Quelle: VOB, Gerichtsurteile): 1 Niederschrift der Vergabeverhandlung 2 Preispositionen 3 Standardbeschreibungen («Vorbemerkungen») 4 Allgemeine Technische Vertragsbedingungen 5 Allgemeine kaufmännische Vertragsbedingungen 6 Baubeschreibung im Leistungsverzeichnis Wurde im Vertrag zwar VOB vereinbart, jedoch durch widersprüchliche andere Passagen verändert, wird der Richter entscheiden, ob die VOB "als Ganzes" oder das BGB dem Vertrag zugrunde lag, denn die vermeintlichen Vereinbarungen waren offensichtlich keine. Vertrag kommt von „vertragen“. Streiten sich die Parteien, geht der Richter davon aus, dass der Vertrag nicht gut war. Er wird auf die gesetzlichen Regelungen zurückgreifen: Im Bauwesen gilt die VOB als Ergänzung zum BGB.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 69

9.4 Die geschuldete Leistung (und Funktions- oder Meldungsversagen) Aus dem Bauvertrag, dem meist der Text der Ausschreibung zugrunde liegt, leitet sich die geschuldete «Leistung» des Aufragnehmers ab. Gerichte legen jedoch auch gerne die sogenannte «branchenübliche Verkehrssitte» bei ungenügend geregelten Punkten zugrunde. In DE ist diese in der VOB (Vergabe- und Vertragsordnung für Bauleistungen) geregelt. Für die Gebäudeautomation gilt hier die VOB/C DIN 18386. Diese wiederum zieht die VDI 3814 als Grundlage heran. Erst wenn im August 2004 die DIN EN ISO 16484 vom Beuth Verlag veröffentlicht wird, kann die VOB/C entsprechend geändert werden. Dann gilt diese GA-Weltnorm.

9.5 Die vertragliche Haftung im Falle von Fehlfunktion, Störung, Personenschaden Bei «Fremdintegration» erfolgt grundsätzlich eine Zuordnung der Verursachungsanteile für Schäden an die Projektpartner bzw. Beteiligten. Eine Verantwortungsübernahme für die «Garantie der Gesamtfunktion» im Falle der Fremdintegration kann nur bei «Arbeitsgemeinschaften» funktionieren. (ARGE = eine [projektbezogene] eigenständige Firma). … oder wenn der Errichter eine Firma ist, z.B. als «Technischer Generalunternehmer» (TGU) und dabei die Verantwortung übernimmt.

Im Schadensfalle erfolgt eine Zuordnung der Verursachungsanteile für Schäden.

9.6 Funktion des "integrierten Gesamtsystems" Bei Systemintegrationen stellt sich die Frage nach der «Gesamtfunktion». Das heisst, wer ist verantwortlich für das «neue Produkt»; das integriertes System, bestehend als vorher unabhängiges Einzelsystem. Offenkundig kann das nur bei Verträgen «aus einer Hand» geregelt werden. Eine «ARGE» (Arbeitsgemeinschaft unabhängiger Firmen) ist eine Sonderform hierfür. Wichtig ist die Erkenntnis, dass die Gesetze keine Verträge «zu Lasten Dritter» erlauben: z.B. «Funktionsgarantie inkl. Drittsystem». Beispiel: Getrennte Vergabe, aber Verantwortungsübernahme für die «Garantie der Gesamtfunktion »? Das Gesetz (z.B. BGB) erlaubt keine derartigen Verträge, siehe oben; d.h. es darf keiner verlangen, dass für ein Dritt- oder Fremdsystem eine «Funktionsgarantie » mit übernommen wird. Beachte! Bei «Fremdkopplungen» als «Vorgabe» durch den Bauherrn haben die einzelnen Firmen kein Vertragsverhältnis mit dem jeweiligen Koppelpartner! Störpotential Bei Kopplungen existiert ein unbegrenztes Störpotential durch Fremdsysteme. Für die Haftung gilt das Verursacherprinzip, daher gilt die grundsätzliche Forderung nach: - Rückverfolgbarkeit, - Nachweisbarkeit, - Dokumentierbarkeit der Fremdeinflüsse. Diese Forderung muss spätestens bei der Vergabeverhandlung aufgestellt und rechtssicher dokumentiert werden! Der BIG-EU / VDI Leitfaden zur Ausschreibung interoperabler GA-Systeme empfiehlt den stationären Einsatz von Protokollanalysatoren mit Speicher.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 70

9.7 Versicherungsaspekte Grundsätzlich berufen sich Versicherungen im Schadensfalle auf die «Regeln der Technik», dazu zählen insbesondere: 1. Die Regeln des Verbands für Schadensverhütung e.V. (VdS, in Deutschland) 2. Die Regeln des Europäischen Verbands der Schadenversicherer (CEA) 3. Entsprechende nationale Normen. Für Europa legt die Organisation «CEA» die versicherungsrelevanten Vorgaben fest. Daraus werden nationale Regeln abgeleitet. Z.B. in Deutschland die Regeln des VdS (Verband Schadensverhütung e.V.) Die Einhaltung der jeweiligen Regeln führt zu einer Reduktion der Versicherungsprämien oder generell zur Versicherbarkeit. Versicherungen stellen die Forderungen auf: a) um überhaupt eine Gefahr zu versichern b) um die Versicherungsprämie («das Risiko») zu reduzieren Eine Übersicht aller gültigen Gesetze und Regeln der Technik für die Gefahrenmeldetechnik bietet die VDI 3819.

9.8 Die wesentlichen Anforderungen Aus Europäischer Sicht gilt für Gebäude die Bauprodukten-Richtlinie. Als wesentliche Anforderung ist darin die Sicherheit definiert: 1. Brandsicherheit 2. Standsicherheit 3. Gesundheit Diese Anforderungen mussten von allen EU- und assoziierten Staaten in nationale Gesetze umgesetzt werden. Daran richten sich auch die geltenden technischen Regeln aus. Man nennt das den «geregelten Bereich». Die gelisteten (mandatierten) meist europäisch harmonisierten Normen sind Grundlage für Systeme der Gebäudesicherheit – im wesentlichen im Bereich Brandsicherheit, der elektrischen und EMV-Sicherheit. Ebenso ist das Produkthaftungsgesetz europäisch harmonisiert. Es gliedert sich in einen verschuldensabhängigen und einen verschuldensunabhängigen Teil.

9.9 Gesetzliche Haftung, verschuldensunabhängig

9.9.1 Wer haftet? Die Produkthaftung und Anlagenhaftung fordert verschuldensunabhängig die gesamtschuldnerische Haftung aller Beteiligten. Den «Systemintegrator» oder «Errichter» als «Drittunternehmer» trifft die: Überwachungshaftung, d.h. Produktbeobachtung (wie z.B. bei Automobilen) und die Auswahlhaftung (Kompatibilität der Produkte); Systemintegrator im Sinne der gesetzlichen Produkthaftung ist, wer die zu integrierenden Produkte bestellt und das daraus entstehende neue Produkt (das integrierte System) verantwortet; – bei getrenntem Einkauf der Systeme ist das meist der Bauherr (ohne sich dessen bewusst zu sein), jedoch sind die Kommunikationspartner und der Beratende Ingenieur ebenso «Beteiligte» im Sinne der Haftung.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 71

Alle Beteiligten haften

9.9.2 Produkthaftung; verschuldensabhängig und verschuldensunabhängig Kommt es in Zusammenhang mit einer Kopplung oder Integration von Systemen zu Meldungsversagen, Fehlfunktionen oder sonstigen Störungen, stellt sich die Frage der Haftung für die daraus resultierenden Schäden. Dies ist nicht nur eine Frage der vertraglichen Haftung bezogen auf die Gewährleistungspflichten der einzelnen beteiligten Unternehmen, es geht auch um die Produkthaftung. Eine Schadenersatzpflicht kann sich aus der deliktischen Produkthaftung (verschuldensabhängig), in Deutschland z.B. nach §823 Abs.1 BGB, und aus dem EU-Produkthaftungsgesetz (verschuldensunabhängig) ergeben. Die Produkthaftung führt zu einer gesamtschuldnerischen Haftung aller am Projekt Beteiligten. Die praktische Erfahrung mit der Rechtsprechung zeigt auf, dass ein grosses Unternehmen in diesen Fällen sogar eine Aufklärungs- und Hinweispflicht gegenüber beteiligten kleineren Firmen hat. (Richter gehen z.B. davon aus, dass bei Siemens das erforderliche Wissen «vorhanden» ist.) Oft muss daher Siemens die Schadensanteile kleinerer «Partner» bei Bauschäden mit übernehmen. Offen ist in der Tat die Frage der Zuordnungsmöglichkeit der Verursachungsanteile für Schäden. Die Risikolage ist ungewiss, da technisch kaum eine Möglichkeit besteht nachzuweisen, wer den Schaden aus einem Meldungsversagen verursacht hat. Ein «Drittsystem» kann eine unbegrenzte Quelle von Störungspotentialen sein. Eine Kombination oder Integration von Sicherungs- und Meldeanlagen mit anderen Systemen ist erst dann akzeptierbar, wenn alle Fremdeinflüsse auf die Gefahrenmeldetechnik rückverfolgbar, nachweisbar und dokumentierbar sind, denn hier geht es um die höchsten Rechtsgüter wie Leib und Leben.

9.10 Pflichten des Systemintegrators oder Errichters

9.10.1 Risiken für Rechtsgüter Haftungsrechtliche Risiken aus der Produkthaftung, z.B. mit Blick auf bestehende Produktbeobachtungs- und Instruktionspflichten bestehen insbesondere dann, wenn diese Produkte nicht für eine Kombination durch «dritte» (Systemintegratoren oder Errichterfirmen) konstruiert wurden. Die Rechtslage bei sogenannten „native“ BACnet Systemen ist noch ungewiss. Es könnte hierbei unterstellt werden, dass diese Produkte für eine Systemintegration durch „dritte“ konstruiert sind. Entsprechende Hinweise in der Produktdokumentation sind erforderlich. Bei der Produkthaftung kommt es auf die ausreichend eindeutige Produktbeschreibung und Unterweisung an. (Dokumentation der sicherheitsrelevanten Informationen nach den geltenden Regeln.) Siehe hierzu auch http://www.ce-richtlinien.de/, dort sind auch die entsprechenden Gesetze und EU-Richtlinien zu finden. Der Drittunternehmer als Systemintegrator kann im Rahmen der Produkthaftung zur Verantwortung gezogen werden. Er haftet für die Auswahl der verwendeten Produkte und deren Kompatibilität (Auswahlhaftung).

9.10.2 Produktbeobachtungs- Pflicht Der Systemintegrator muss seine oft immateriellen Leistungen (z.B. Software) überwachen und über den Produktlebenszyklus hinweg prüfen, ob Fehler auftreten (Überwachungshaftung). Die Organisationsverantwortung hierfür hat die Geschäftsleitung des betroffenen Unternehmens. Die rechtlichen Gefahren, welche sich mit einer Systemintegration durch Dritte ergeben, lassen sich nur schwer vorhersehen. Das gilt nicht nur für Integrationen oder Kopplungen von sicherheitstechnischen Einrichtungen untereinander, sondern insbesondere auch bei Kombinationen der Gefahrenmeldetechnik

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 72

mit Einrichtungen der Gebäudeautomation und bei Verwendung der Gebäudeautomation für Gefahrenmeldungen der Sicherungstechnik. Die kommende «Betriebssicherheitsverordnung» bzw. die «EU-Anlagenrichtlinie» wird neue restriktive Vorgaben bringen, welche insbesondere dem Betreiber von Systemen und Anlagen eine höhere Verantwortung aufbürden. Das Thema "aus einer Hand" bekommt damit neue Aktualität.

9.10.3 Datenschutz Ebenso gelten die öffentlichen Schutzaspekte für personenbezogene Daten nach dem Datenschutzgesetz, wenn Zutrittskontroll- und Zeiterfassungssysteme mit betroffen sind.

9.11 Gesetzliche Haftung, verschuldensabhängig Nach § 823 Abs.1 BGB handelt es sich bei Personenschäden (Verletzung höchster Rechtsgüter, wie Leib und Leben) um eine deliktische Haftung. Ein Verschulden (fahrlässig, grobfahrlässig oder mutwillig) bestimmt das Strafmass. Das Datenschutzgesetz bestimmt die Behandlung personenbezogener Daten, z.B. bei Zutrittskontrolle und Zeiterfassung.

9.12 Normen (speziell fürs Gefahrenmanagement)

9.12.1 Lokale Regeln Die DIN 276 zur Ermittlung der Kosten im Hochbau definiert unter der Kostengruppe «Fernmelde- und Informationstechnische Anlagen» als Untergruppe 456 die Gefahrenmelde- und Alarmanlagen (GMA). Diese Gliederung wird in der Regel für Bauverträge, aber auch für die Erstellung von technischen Regelwerken und Normen angewendet. Lokale Vorschriften beschreiben neben gerätetechnischen Anforderungen vor allem die Planung, Errichtung und den Betrieb von Brandmeldeanlagen. Für die Umsetzung dieser Vorschriften sorgen bei den brandschutztechnischen Massnahmen der vorbeugende Brandschutz der lokalen Behörden, der Feuerwehr und Polizei im Rahmen der Baugenehmigung. Die Sachversicherer sowie die Berufsgenossenschaften übernehmen diese Aufgabe bei den Überfall- und Einbruchmeldeanlagen.

9.12.2 Nationale Regeln (z.B. DE) Normen und Bestimmungen DIN 14675 VDE 0165, 0800, 0833 Richtlinien des VdS (Verband Schadensverhütung e.V.) IfBT (Institut für Bautechnik, Berlin) Verordnungen, (Gesetze) Länder-Bauordnungen

9.12.3 Europäische Regeln Die Normenreihe EN54 «Brandmeldeanlagen»

9.12.4 Weitere Informationen über Technische Regeln VDI 3819-1 (Jan/2002), Brandschutz in der Gebäudetechnik – Gesetze, Verordnungen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 73

und Technische Regeln. VDI 6010 Sicherheitstechnik – Systemübergreifende Funktionen; Und: VDI 3814-2:2004(E) (neu) Gesetze, Verordnungen und Regeln der Technik für Gebäudeautomation.

9.13 Grundlagen der Sicherheit Der Wunsch des Menschen nach Sicherheit ist so alt wie die Menschheit selbst. Er, der Mensch hat daher immer wieder versucht, das Erreichte – vor allem Hab und Gut – gut zu sichern, denn Brände, Raub, Umweltkatastrophen usw. stellten immer wieder das Erreichte in Frage. In der modernen Psychologie hat Prof. Maslow wissenschaftlich erkannt, dass das Sicherheitsbedürfnis – nach Trinken und Essen – ein Grundbedürfnis des Menschen ist: Die Maslow-Pyramide 1 Grundbedürfnisse: Hunger, Durst, Schlaf, Bewegungsdrang 2 Schutzbegehren: Sicherheitsbedürfnis 3 Soziale Bedürfnisse: Freundschafts- und Liebesbedürfnis 4 Selbstachtung: Prestige und Statusbedürfnis 5 Selbstverwirklichung: Fähigkeiten und Neigungen Das Sicherheits-/Schutzbedürfnis ist ein Grundbedürfnis des Menschen. Nach Prof. Maslow lassen sich die weiteren Bedürfnisse entsprechend der Bedürfnispyramide wie folgt zuordnen: - Haus und Gebäude (baulicher Schutz) - Heizung und Lüftung (mit Automation) - Gefahrenmeldetechnik - Klimatechnik (mit Automation) - Systemintegration - HighTech und durch: A) Abschluss von Verträgen und Versicherungen B) Regelwerke / Gesetze / grundlegende Anforderungen: z.B. Bauproduktenrichtlinie / Anlagenrichtlinie: - Brand- und Standsicherheit, - mechanische & elektrische Sicherheit, - CE-Kennzeichnung

9.14 Hilfestellung Geht es um die technische Bewertung der Ausschreibung nach VOB/C, die Machbarkeit der ausgeschriebenen MSR-Technik generell oder um Gebäudesystemtechnik, können folgende vereidigte Gutachter helfen: Prof. S. Baumgarth, Braunschweig, Prof. Manfred Büchel, Gelsenkirchen, Edwin Hadré, Rösrath(VDI 3814 Obmann), Viktor Höschele, Canzler Ingenieure, Dresden. (Adressen – und weitere Gutachter - finden sich in der Gutachterliste des VDI-TGA, ([email protected]), Hans R. Kranz ([email protected]) kann ggf. weitere passende Empfehlungen (auch für Rechtsfragen zur VOB) geben).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 74

Anhang A BACnet Interoperability Building Blocks (BIBBs) Die BACnet Interoperabilitätsbausteine (BIBBs) sind eine Sammlung von einem oder mehreren BACnet-Diensten. Diese sind beschrieben in Form von A und B Devices. Diese Einrichtungen sind Teilnehmer in einem BACnet-Netzwerk. In den meisten Anwendungen wird Device A (Anforderer) als Client (Nutzer) und Device B (Bereithalter) als Server (Datenquelle) dienen. In manchen Anwendungen gibt es normative und optionale BIBBs. Für manche Bacnet-Objekte oder Properties kann es spezifische Einschränkungen bezüglich der Werte oder Dienst-Parameter geben.

A.0 BIBBs Zusammenfassung als „Handliste“

BIBB Kürzel BIBB Bezeichnung DS- Gemeinsame Datennutzung (Data Sharing BIBBs) DS-RP-A/B BIBB – Data Sharing-ReadProperty-A/B, A liest Property von B. DS-RPM-A/B BIBB – Data Sharing-ReadPropertyMultiple-A/B, A liest mehrere Werte gleichzeitig von B. DS-RPC-A/B BIBB – Data Sharing-ReadPropertyConditional-A/B, A liest gem. Bedingung Property von

B. DS-WP-A/B BIBB – Data Sharing-WriteProperty-A/B, A schreibt auf Property in B. DS-WPM-A/B BIBB – Data Sharing-WritePropertyMultiple-A/B, A schreibt mehrere Werte gleichzeitig in

B. DS-COV-A/B BIBB – Data Sharing-COV-A/B, A abonniert Informationen über Wertänderungen von B. DS-COVP-A/B BIBB – Data Sharing-COVP-A/B, A abonniert Informationen über Wertänderungen eines

speziellen Property von B. DS-COVU-A/B BIBB – Data Sharing-COV-Unsolicited-A/B, A verarbeitet unaufgefordert gesandte COV-

Werte von B. AE- Alarm und Ereignis-Management (Alarm and Event Management BIBBs) AE-N-A BIBB – Alarm and Event-Notification-A, A verarbeitet Meldungen von B. AE-N-I-B BIBB – Alarm and Event-Notification Internal-B, B erzeugt Meldungen

(unterstützt objektinternes (intrinsic) und regelbasiertes (algorithmic) Melden (reporting). AE-N-E-B BIBB – Alarm and Event-Notification External-B, B erzeugt Meldungen (regelbasiert mit

Ereigniskategorie-Objekt). AE-ACK-A/B BIBB – Alarm and Event-ACK-A/B, A quittiert Meldungen von B. AE-ASUM-A/B BIBB – Alarm and Event-Alarm Summary-A/B, A fordert Meldungslisten bei B an. (Der

GetAlarmSummary-Dienst ist geeignet, aktiv anstehende Alarme abzurufen. Ausstehende Alarm-Quittierungen für zwischenzeitlich wieder nach "Normal" gewechselte Meldungen werden dabei nicht erfasst; BACnet 1995, siehe AE-INFO-A/B).

AE-ESUM-A/B BIBB – Alarm and Event-Enrollment Summary-A/B, A fordert die Empfängerliste für ein Ereignis bei B an. (Der "GetEnrollmentSummary" Dienst bietet die Möglichkeit alle potenziellen Quellen für Ereignismeldungen abzufragen).

AE-INFO-A/B BIBB – Alarm and Event-Information-A/B, A fordert Ereignis-Informationen bei B an.(Der "GetEventInformation"-Dienst ergänzt den "GetAlarmSummary"-Dienst, in dem er auch ausstehende Quittierungen mit Zeitstempel liefert und jedes Ereignis benennt, ohne sich nur auf Alarme zu fokussieren. Der "GetEventInformation"-Dienst ist als Ablösung des "GetAlarmSummary"-Diensts vorgesehen. (BACnet 2001)

AE-LS-A/B BIBB – Alarm and Event-LifeSafety-A/B, A fordert Alarmruhe oder Alarmrücksetzung von Gefahrenmeldeeinrichtung B.

SCHED- Zeitplan (Scheduling BIBBs) SCHED-A BIBB – Scheduling-A, A verändert Zeitplaneinstellungen in B. SCHED-I-B BIBB – Scheduling-Internal-B, B führt bis zu 6 eingetragene Schaltungen pro Tag bei

eigenen Datenpunkten aus. SCHED-E-B BIBB – Scheduling-External-B, B führt bis zu 6 eingetragene Schaltungen pro Tag bei

Datenpunkten im GA-Netzwerk aus. T- Trendaufzeichnung (Trending BIBBs)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 75

BIBB Kürzel BIBB Bezeichnung T-VMT-A BIBB – Trending-Viewing and Modifying Trends-A, A fordert Trendwerte von B und zeigt

diese an. T-VMT-I-B BIBB – Trending-Viewing and Modifying Trends Internal-B, B sammelt Trendwerte eigener

Datenpunkte für A. T-VMT-E-B BIBB – Trending-Viewing and Modifying Trends External-B, B sammelt Trendwerte von

Datenpunkten im GA-Netzwerk für A. T-ATR-A/B BIBB – Trending-Automated Trend Retrieval-A/B, A reagiert auf die Meldung von B, dass

die gesammelten Trendwerte zur Abholung bereit stehen. T-VMMV-A BIBB – Trending-Viewing and Modifying Multiple Values-A, A zeigt die Daten der

Trendwerte von B und verändert die Trendparameter in B. T-VMMV-I-B BIBB – Trending-Viewing and Modifying Multiple Values-Internal –B, B sammelt

Mehrfach-Trendwerte im eigenen Device. T-VMMV-E-B BIBB – Trending-Viewing and Modifying Multiple Values-External –B, B sammelt

Mehrfach-Trendwerte auch von anderen Devices. T-AMVR-A/B BIBB – Trending-Automated Multiple Value Retrieval-A/B,

A reagiert auf eine Meldung von einem Mehrfach-Trend-Objekt und holt die neuen Daten von der Aufzeichnung. B Meldet, dass der Zwischenspeicher eines Mehrfachtrend-Objekts die vorgegebene Werteanzahl hat

DM/NM- Device- und Netzwerkmanagement, (Device and Network Management BIBBs) DM-DDB-A/B BIBB – Device Management-Dynamic Device Binding-A/B, A sucht Informationen über

andere Devices im GA-Netzwerk und interpretiert entsprechende Ankündigungen (Who-Is / I-Am)

DM-DOB-A/B BIBB – Device Management-Dynamic Object Binding-A/B, A sucht im GA-Netzwerk Adressinformationen über BACnet-Objekte (Who-Has, I-Have)

DM-DCC-A/B BIBB – Device Management-DeviceCommunicationControl-A/B, A übt die Kontrolle über das Kommunikationsverhalten von B aus.

DM-PT-A/B BIBB – Device Management-Private Transfer-A/B, A löst die Übertragung proprietärer Daten von B mittels eines BACnet-Dienstes aus.

DM-TM-A/B BIBB – Device Management-Text Message-A/B, A löst die Übertragung von freiem Text für B aus.

DM-TS-A/B BIBB – Device Management-TimeSynchronization-A/B, A stellt B eine Zeitsynchronisierung mit der lokalen Uhrzeit zur Verfügung.

DM-UTC-A/B BIBB – Device Management-UTCTimeSynchronization-A/B, A stellt B eine Zeitsynchronisierung mit der UTC-Weltzeit (GMT) zur Verfügung.

DM-RD-A/B BIBB – Device Management-ReinitializeDevice-A/B, A veranlasst B zu einem Warm- oder Kaltstart der Software.

DM-BR-A/B BIBB – Device Management-Backup and Restore A/B, A liest die Konfigurationsdaten von B und schreibt diese bei Bedarf zurück.

DM-R-A/B BIBB – Device Management-Restart-A/B, A verarbeitet Wiederanlauf-Meldungen von B mit Interpretation der Gründe.

DM-LM-A/B BIBB – Device Management-List Manipulation-A/B, A fügt Listenelemente in Properties von B hinzu oder entfernt diese.

DM-OCD-A/B BIBB – Device Management-Object Creation and Deletion-A/B, A erstellt oder entfernt BACnet-Objekttypen in B.

DM-VT-A/B BIBB – Device Management-Virtual Terminal-A/B, A startet eine Virtual Terminal Sitzung mit B (direkte Kommunikation mit dem B Prozessor).

NM-CE-A/B BIBB – Network Management-Connection Establishment-A/B, A veranlasst Modems (Halbrouter) zum Auf- und Abbau von Verbindungen, B führt diese Kommandos aus.

NM-RC-A/B BIBB – Network Management-Router Configuration-A/B, A fragt die Konfigurationsdaten von Routern und Modems ab und veranlasst deren Änderung, B reagiert auf diese Kommandos.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 76

A.1 Data Sharing BIBBs Diese BIBBs beschreiben die BACnet Merkmale für die interoperable Unterstützung der Funktionen für den Datenaustausch wie sie in 3.2 beschrieben sind.

A.1.1 BIBB – Data Sharing-ReadProperty-A (DS-RP-A) Das Device A ist der Nutzer der Daten von Device B

BACnet Service Initiate ExecuteReadProperty x

A.1.2 BIBB – Data Sharing-ReadProperty-B (DS-RP-B) Das Device B ist der Anbieter von Daten für Device A

BACnet Service Initiate ExecuteReadProperty x

A.1.3 BIBB – Data Sharing-ReadPropertyMultiple-A (DS-RPM-A) Das Device A ist Nutzer von Daten von Device B und fordert gleichzeitig mehrere Daten an.

BACnet Service Initiate ExecuteReadPropertyMultiple x

A.1.4 BIBB – Data Sharing-ReadPropertyMultiple-B (DS-RPM-B) Das Device B ist Anbieter von Daten für Device A und schickt mehrere Daten gleichzeitig.

BACnet Service Initiate ExecuteReadPropertyMultiple x

A.1.5 BIBB – Data Sharing-ReadPropertyConditional-A (DS-RPC-A) Das Device A ist der Nutzer von Daten von Device B und fordert diese Daten in Abhängigkeit von bestimmten Kriterien die in der Anforderungs-Nachricht enthalten sind an.

BACnet Service Initiate ExecuteReadPropertyConditional x

A.1.6 BIBB – Data Sharing-ReadPropertyConditional-B (DS-RPC-B) Das Device B ist der Anbieter von Daten für Device A und stellt diese Daten in Abhängigkeit von bestimmten Kriterien die in der Anforderung von Device A enthalten sind zur Verfügung.

BACnet Service Initiate ExecuteReadPropertyConditional x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 77

A.1.7 BIBB – Data Sharing-WriteProperty-A (DS-WP-A) Das Device A setzt (verstellt) einen Wert in Device B

BACnet Service Initiate ExecuteWriteProperty x

A.1.8 BIBB – Data Sharing-WriteProperty-B (DS-WP-B) Das Device B erlaubt die Verstellung eines Wertes durch Device A.

BACnet Service Initiate ExecuteWriteProperty X

A.1.9 BIBB – Data Sharing-WritePropertyMultiple-A (DS-WPM-A) Das Device A setzt (verstellt) gleichzeitig mehrere Werte in Device B

BACnet Service Initiate ExecuteWritePropertyMultiple x

A.1.10 BIBB – Data Sharing-WritePropertyMultiple-B (DS-WPM-B) Das Device B erlaubt die gleichzeitige Verstellung mehrerer Werte durch Device A.

BACnet Service Initiate ExecuteWritePropertyMultiple x

A.1.11 BIBB – Data Sharing-COV-A (DS-COV-A) Das Device A ist Anforderer (Nutzer) von COV- (Wertänderungs-) Daten von Device B

BACnet Service Initiate ExecuteSubscribeCOV X ConfirmedCOVNotification X UnconfirmedCOVNotification X

Unterstützung für eine festgelegte Zeit ist gefordert, für unbegrenzte Zeit ist optional.

A.1.12 BIBB – Data Sharing-COV-B (DS-COV-B) Das Device B ist Bereitsteller von COV-(Wertänderungs-) Daten für Device A

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 78

BACnet Service Initiate ExecuteSubscribeCOV X ConfirmedCOVNotification X UnconfirmedCOVNotification X

DS-COV-B konforme Devices müssen mindestens 5 gleichzeitige Abonnements unterstützten. Unterstützung für eine festgelegte Zeit ist gefordert, für unbegrenzte Zeit ist optional.

A.1.13 BIBB – Data Sharing-COV-Property-A (DS-COVP-A) Das Device A ist Anforderer (Nutzer) von COV- (Wertänderungen) von ausgesuchten Properties eines spezifizierten Objekts in Device B

BACnet Service Initiate ExecuteUnconfirmedCOVNotification x

Unterstützung für eine festgelegte Zeit ist gefordert, für unbegrenzte Zeit ist optional.

A.1.14 BIBB – Data Sharing-COV-Property-B (DS-COVP-B) Das Device B generiert COV Mitteilungen von ausgesuchten Properties eines spezifizierten Objekts für Device A

BACnet Service Initiate ExecuteUnconfirmedCOVNotification X

DS-COVP-B konforme Devices müssen mindestens 5 gleichzeitige Abonnements unterstützten, Unterstützung für eine festgelegte Zeit ist gefordert, für unbegrenzte Zeit ist optional.

A.1.15 BIBB – Data Sharing-COV-Unsolicited-A (DS-COVU-A) Das Device A verarbeitet spontane (nicht angeforderte, "unsubsribed") COV-Daten von Device B

BACnet Service Initiate ExecuteUnconfirmedCOVNotification x

A.1.16 BIBB – Data Sharing-COV-Unsolicited-B (DS-COVU-B) Das Device B generiert spontane (nicht angeforderte) COV Mitteilungen

BACnet Service Initiate ExecuteUnconfirmedCOVNotification X

A.2 Alarm and Event Management BIBBs Diese BIBBs beschreiben die BACnet Merkmale für die interoperable Unterstützung für die Funktionen Alarm-Management und Ereignis-Management wie sie in 3.3 für BACnet-Devices beschrieben sind.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 79

A.2.1 BIBB – Alarm and Event-Notification-A (AE-N-A) Das Device A bearbeitet Mitteilungen über Alarme und andere Ereignisse

BACnet Service Initiate ExecuteConfirmedEventNotification x UnconfirmedEventNotification x

A.2.2 BIBB – Alarm and Event-Notification-B (AE-N-B) Device B generiert Mitteilungen über Alarme oder andere Ereignisse

BACnet Service Initiate ExecuteConfirmedEventNotification x UnconfirmedEventNotification x

AE-N-B konforme Devices müssen entweder Intrinsic (objekteigenes Melden) oder Algorithmic Reporting (mittels Ereigniskategorieobjekten) unterstützten.

A.2.3 BIBB – Alarm and Event-ACK-A (AE-ACK-A) Device A bestätigt Alarm-/Ereignismitteilungen

BACnet Service Initiate ExecuteAcknowledgeAlarm x

A.2.4 BIBB – Alarm and Event-ACK-B (AE-ACK-B) Devices B bearbeitet Bestätigungen von zuvor übertragenen Alarm-/Ereignismitteilungen

BACnet Service Initiate ExecuteAcknowledgeAlarm x

Für dieses BIBB muss das Device auch quittierbare Alarme unterstützen.

A.2.5 BIBB – Alarm and Event-Summary-A (AE-ASUM-A) Device A fordert Alarmübersichten von Device B an.

BACnet Service Initiate ExecuteGetAlarmSummary x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 80

A.2.6 BIBB – Alarm and Event-Summary-B (AE-ASUM-B) Device B stellt Device A Alarmübersichten zur Verfügung

BACnet Service Initiate ExecuteGetAlarmSummary x

A.2.7 BIBB – Event-Summary-A (AE-ESUM-A) Device A fordert Abonnement-Eintragungen für Ereignisnachrichten von Device B an

BACnet Service Initiate ExecuteGetEnrollmentSummary x

A.2.8 BIBB – Event-Summary-B (AE-ESUM-B) Device B stellt Abonnement-Eintragungen für Ereignisnachrichten Device A zur Verfügung

BACnet Service Initiate ExecuteGetEnrollmentSummary x

A.3 Scheduling BIBBs Diese BIBBs beschreiben die BACnet Merkmale für die interoperable Unterstützung für die Funktion Zeitprogramm (Zeitplan) wie sie in 3.4 für BACnet-Devices beschrieben sind.

A.3.1 BIBB – Scheduling-A (SCHED-A) Das Device A bearbeitet Zeitpläne und Kalendereinträge im Device B. Das Device A muss DS-RP-A und DS-WP-A BIBBs unterstützen.

A.3.2 BIBB – Scheduling-B (SCHED-B) Das Device B unterstützt/bietet Datum- und Zeitplanmanagement von Werten für spezifische Properties von spezifischen Objekten an. Zusätzlich zur Unterstützung von DS-RP-B und DS-WP-B BIBBs, muss jedes Device mit SCHED-B Konformität mindestens über ein Betriebskalender-, ein Zeitplan- und ein Gruppenauftrag-Objekt verfügen. Das Gruppenauftrag-Objekt wird für Zeitplan-Aktionen in anderen Devices benötigt. Das Zeitplanobjekt muss mindestens 6 Einträge pro Tag und mindestens einen Eintrag für das List_of_Object_Property_Reference Property unterstützen. Das Zeitplanobjekt muss einen nicht leeren Ausnahme-Zeitplan (Exception_Schedule) Eintrag erlauben. Das Gruppenauftrag-Objekt muss in der Lage sein, auf Properties in Objekten anderer Devices zu schreiben. Die Überschreib-Priorität (Priority_For_Writing Property) des Zeitplan-Objekts (schedule object type) muss überschreibbar sein.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 81

A.4 Trending BIBBs Diese BIBBs beschreiben die BACnet Merkmale für die interoperable Unterstützung der Funktionen für die Trendwertverarbeitung wie sie in 3.5 für BACnet-Devices beschrieben sind.

A.4.1 BIBB – Viewing and Modifying Trends-A (T-VMT-A) Das Device A zeigt Trend-Daten (Zeitreihendiagramme) vom Device B an und bearbeitet Einstellungen für die Trendwerterfassung im Device B

BACnet Service Initiate ExecuteReadRange x

A.4.2 BIBB – Viewing and Modifying Trends-B (T-VMT-B) Device B sammelt Trenddaten in einem internen Speicher. Jedes T-VMT-B konforme Device muss mindestens ein Trendaufzeichnungs-Objekt (trend log object) unterstützen.

BACnet Service Initiate ExecuteReadRange x

Man unterscheidet auch (K.4.2) T-VMT-I-B (intern) und (K.4.3) T-VMT-E-B (extern); Bei „extern“ kann das B Device Properties von Objekten in anderen Devices speichern, hierzu muss es DS-RP-A unterstützen.

A.4.3 BIBB – Trending – Automated Trend Retrieval-A (T-ATR-A) Das Device A reagiert auf die Benachrichtigung, dass ein Trendaufzeichnungsspeicher nun neue Einträge verfügbar hat, und nimmt die neuen Trenddaten vom Trendspeicher entgegen.

BACnet Service Initiate ExecuteConfirmedEventNotification x ReadRange x

T-ATR-A konforme Devices müssen Trendaufzeichnungs-Objekte (trend log object types) und Ereigniskategorieobjekte (event enrollment objects) unterstützten.

A.4.4 BIBB – Trending – Automated Trend Retrieval-B (T-ATR-B) Das Device B benachrichtigt Device A, dass sich in einem Trendaufzeichnungsspeicher eine festgelegte Anzahl von Einträgen angesammelt hat.

BACnet Service Initiate ExecuteConfirmedEventNotification x ReadRange x

T-ATR-B konforme Devices müssen das Trendaufzeichnungs-Objekt unterstützen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 82

A.5 Device Management BIBBs Diese BIBBs beschreiben die BACnet Merkmale für die interoperable Unterstützung der Devicemanagement-Funktionen wie sie in 3.6 beschrieben sind.

A.5.1 BIBB - Device Management - Dynamic Device Binding - A (DM-DDB-A) Das Device A sucht Informationen über Device-Properties (Attribute) anderer Devices und interpretiert deren Ankündigungen.

BACnet Service Initiate Execute Who-Is x I-Am x.

A.5.2 BIBB - Device Management - Dynamic Device Binding - B (DM-DDB-B) Das Device B stellt Informationen über seine eigenen Device-Properties (Attribute) zur Verfügung und reagiert auf die Anforderung sich zu identifizieren.

BACnet Service Initiate Execute Who-Is x I-Am x

A.5.3 BIBB - Device Management - Dynamic Object Binding - A (DM-DOB-A) Das Device A sucht Adressinformationen von BACnet Objekten.

BACnet Service Initiate Execute Who-Has x I-Have x

A.5.4 BIBB - Device Management - Dynamic Object Binding - B (DM-DOB-B) Das Device B stellt Adressinformationen über seine Objekte auf Anfrage zur Verfügung.

BACnet Service Initiate Execute Who-Has x I-Have x

A.5.5 BIBB - Device Management - DeviceCommunicationControl - A (DM-DCC-A) Das Device A übt die Kommunikationssteuerung über Device B aus.

BACnet Service Initiate Execute DeviceCommunicationControl x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 83

A.5.6 BIBB - Device Management - DeviceCommunicationControl - B (DM-DCC-B) Das Device B reagiert auf die von Device A ausgeübte Kommunikationssteuerung.

BACnet Service Initiate Execute DeviceCommunicationControl x

A.5.7 BIBB - Device Management - PrivateTransfer - A (DM-PT-A) Das Device A initiiert die Übertragung von Nicht-BACnet-Daten mittels eines BACnet Service- Requests. Die Interpretation der Daten ist herstellerspezifisch.

BACnet Service Initiate Execute ConfirmedPrivateTransfer x UnconfirmedPrivateTransfer x

A.5.8 BIBB - Device Management - PrivateTransfer - B (DM-PT-B) Das B-Device verarbeitet Nicht-BACnet-Daten, die in einen BACnet Service-Request enthalten sind.

BACnet Service Initiate Execute ConfirmedPrivateTransfer x UnconfirmedPrivateTransfer x

A.5.9 BIBB - Device Management - Text Message - A (DM-TM-A) Das A-Device initiiert die Übertragung von Text-Meldungen. Die Interpretation und darauffolgende Verarbeitung der Meldungen ist herstellerspezifisch.

BACnet Service Initiate Execute ConfirmedTextMessage x UnconfirmedTextMessage x

A.5.10 BIBB - Device Management - Text Message - B (DM-TM-B) Das B-Device verarbeitet Text-Meldungen.

BACnet Service Initiate Execute ConfirmedTextMessage x UnconfirmedTextMessage x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 84

A.5.11 BIBB - Device Management - TimeSynchronization - A (DM-TS-A) Das A-Device stellt die Zeitsynchronisation für B-Devices zur Verfügung. Die im Service-Request enthaltenen Zeitparameter enthalten Datum und Zeit wie sie für die Uhr des den Service-Requests aussendenden Device bestimmt sind. Normalerweise ist das die Ortszeit, also die Zeit der lokalen Zeitzone korrigiert um die Verschiebung durch die Sommerzeit, soweit erforderlich.

BACnet Service Initiate Execute TimeSynchronization x DM-TS-A konforme Devices müssen das Time_Synchronization_Recipients Property des Device Objektes unterstützen.

A.5.12 BIBB - Device Management - TimeSynchronization - B (DM-TS-B) Das B-Device interpretiert Zeitsynchronisationsmeldungen von einem A-Device.

BACnet Service Initiate Execute TimeSynchronization x DM-TS-B konforme Devices müssen in ihrem Device Objekt die BACnet-Properties Local_Time und Local_Date unterstützen.

A.5.13 BIBB - Device Management - UTCTimeSynchronization - A (DM-UTC-A) Das A-Device stellt die Zeitsynchronisation für B-Devices zur Verfügung. Die Zeitparameter der Service Requests enthalten die „Coordinated Universal Time“ (UTC). UTC ist für alle praktischen Anwendungen mit der Zeit des Nullmeridians, der Greenwich-Zeit, gleichzusetzen.

BACnet Service Initiate Execute UTCTimeSynchronization X

DM-UTC-A konforme Devices müssen das Time_Synchronization_Recipients Property des Device Objektes unterstützen.

A.5.14 BIBB - Device Management - UTCTimeSynchronization - B (DM-UTC-B) Das B-Device interpretiert UTC-Zeitsynchronisationsmeldungen von einem A-Device.

BACnet Service Initiate Execute UTCTimeSynchronization x

DM-UTC-B konforme Devices müssen die Properties Local_Time, Local_Date, UTC_Offset und Daylight_Saving_Status des Device Objektes unterstützen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 85

A.5.15 BIBB - Device Management - ReinitializeDevice - A (DM-RD-A) Das A-Device ist berechtigt die Programme im B-Device neu zu starten.

BACnet Service Initiate Execute ReinitializeDevice x

DM-RD-A konforme Devices müssen in der Lage sein, ReinitializeDevice Requests zu initiieren, die den Passwort-Parameter enthalten. Dieses muss für Warm- und Kaltstart möglich sein.

A.5.16 BIBB - Device Management - ReinitializeDevice - B (DM-RD-B) Das B-Device führt ein Programm-Start-Kommando eines A-Gerätes aus. Das optionale Passwort- Feld ist zu unterstützen.

BACnet Service Initiate Execute ReinitializeDevice x

A.5.17 BIBB - Device Management - Backup and Restore - A (DM-BR-A) Das A-Device liest die Dateien (Upload), welche die Konfiguration des B Device enthalten und schreibt diese Dateien auf das B-Device zurück (Download), sollte dieses eine Wiederherstellung des vorherigen Backup-Zustandes benötigen.

BACnet Service Initiate Execute AtomicReadFile x AtomicWriteFile x Create Object x ReinitializeDevice x

DM-BR-A konforme Devices müssen den Wert TRUE nach einer Backup Operation in das Archive Property des Dateiobjektes schreiben, welches die Konfigurationsdatei im B-Device repräsentiert. Konfigurationsdateien Up- und Downloads müssen als Stream-orientierte Dateizugriffe ausgeführt sein. (Siehe Kapitel 19.1 der Norm).

A.5.18 BIBB - Device Management - Backup and Restore - B (DM-BR-B) Das B-Device stellt seine Konfigurationsdatei dem A-Device zur Verfügung, und erlaubt dem A-Device diese Datei zur Wiederherstellung der Konfiguration nach einem Ausfall zu laden.

BACnet Service Initiate Execute AtomicReadFile x AtomicWriteFile x ReinitializeDevice x

In DM-BR-B konformen Devices müssen nach einem Download das Read_Only Property für Datei-Objekte, welche die Konfigurationsdatei repräsentieren, den Wert FALSE enthalten, das File_Type Property muss den Wert CONFIGURATION enthalten und das File_Size Property muss schreibbar sein. Ladeprozesse für Konfigurationsdateien müssen mittels stream-orientierten Dateizugriffs ausgeführt werden.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 86

Für das Zurückschreiben der Konfigurationsdatei (Download) siehe Kapitel 19.1.3.3 in DIN EN ISO 16484-5

A.5.18a BIBB - Device Management – Restart - A (DM-R-A) Das A-Device bearbeitet Mitteilungen über einen Neustart.

BACnet Service Initiate Execute UnconfirmedCOVNotification X

A.5.18b BIBB - Device Management - Restart - B (DM-R-B) Das B-Device informiert A Device(s) über jedem Neustart.

BACnet Service Initiate Execute UnconfirmedCOVNotification X

A.5.19 BIBB - Device Management - List Manipulation - A (DM-LM-A) Viele BACnet Objekttypen haben Properties, die aus Listen einer bestimmten Datenart bestehen. Das A-Device kann Listenelemente in den Properties des B-Gerätes hinzufügen und entfernen.

BACnet Service Initiate Execute AddListElement x RemoveListElement x

A.5.20 BIBB - Device Management - List Manipulation - B (DM-LM-B) Das B-Device reagiert auf die Aufforderungen ein Listenelement hinzuzufügen oder zu entfernen.

BACnet Service Initiate Execute AddListElement x RemoveListElement x

A.5.21 BIBB - Device Management - Object Creation and Deletion - A (DM-OCD-A) BACnet erlaubt es, Objekt Instanzen dynamisch zu erzeugen und zu löschen. Ein A-Device kann dynamisch (im laufenden Betrieb) Objekttypen, die vom B-Device unterstützt werden, erzeugen und löschen.

BACnet Service Initiate Execute CreateObject x DeleteObject x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 87

A.5.22 BIBB - Device Management - Object Creation and Deletion - B (DM-OCD-B) Das B-Device erzeugt und löscht Objekt Instanzen auf Anforderung des A-Gerätes. Die Objekttypen, für die dynamisches Erzeugen und Löschen unterstützt wird, müssen in den PICS des B-Gerätes aufgelistet sein.

BACnet Service Initiate Execute CreateObject x DeleteObject x

A.6 Virtual Terminal BIBBs Virtual Terminal Services erlauben Fernzugriff auf Feldgeräte und Automationseinrichtungen über ein BACnet Netzwerk. Der Zweck ist einen Zugriff auf proprietäre Konfigurations- und Diagnosefunktionen von einer Bedien- oder Managementeinrichtung aus, als wenn diese direkt mit dem BACnet Device verbunden wäre.

A.6.1 BIBB - Device Management – Virtual terminal - B (DM-VT-A) Das A-Device initiiert eine Virtual Terminal Sitzung und tauscht Daten mit dem B Device aus.

BACnet Service Initiate Execute VT-Open X VT-Close X x VT-Data x X

A.6.2 BIBB - Device Management – Virtual terminal - B (DM-VT-B) Das B-Device Erlaubt die Einrichtung einer Virtual Terminal Sitzung und tauscht Daten mit dem A Device aus.

BACnet Service Initiate Execute VT-Open X VT-Close X x VT-Data x X

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 88

A.7 Network Management BIBBs Diese BIBBs beschreiben die Merkmale, die BACnet für interoperable Netzwerk-Managementfunktionen vorsieht. Vergleiche dazu Kapitel 3.5 (Beschreibung der BACnet Netzwerke).

A.7.1 BIBB - Network Management - Connection Establishment - A (NM-CE-A) Ein A-Device befiehlt einem Halb-router eine Verbindung, die für die Kommunikation mit anderen Devices benötigt wird, nach Anforderung aufzubauen bzw. zu trennen.

BACnet Network Layer Message Initiate Execute Establish-Connection-To-Network x Disconnect-Connection-To-Network x

A.7.2 BIBB - Network Management - Connection Establishment - B (NM-CE-B) Das B-Device führt die Kommandos zum Aufbau bzw. Trennung einer Verbindung nach Anforderung aus.

BACnet Network Layer Message Initiate Execute Establish-Connection-To-Network x Disconnect-Connection-To-Network x

A.7.3 BIBB - Network Management - Router Configuration - A (NM-RC-A) Ein A-Device kann die Konfiguration eines Routers und Halb-Routers abfragen und ändern. Die Merkmale der Router und Halb-router sind in Kapitel 6 der BACnet Protokollbeschreibung festgelegt. Somit werden keine expliziten BIBBs benötigt.

BACnet Network Layer Message Initiate Execute Who-Is-Router-To-Network x I-Am-Router-To-Network x I-Could-Be-Router-To-Network x Initialize-Routing-Table x Initialize-Routing-Table-Ack x

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 89

Anhang B BACnet Device - Profile (Descriptions and Profiles of Standardized BACnet Devices) Dieses Kapitel beschreibt fünf „standardisierte“ BACnet „Device-types“. Jede Einrichtung (device) die alle geforderten BACnet Elemente für die Interoperabilität eines bestimmten IOB implementiert hat, ist ein Device-type der bezeichneten Art. BACnet Device können auch zusätzliche Fähigkeiten anbieten, welche dann in den PICS angegeben sein müssen. Die in diesem Kapitel definierten Device-types sind: - BACnet Operator Workstation (Bedien- und/oder Managementeinrichtung), - BACnet Building Controller (Automationsstation, programmierbare Automationseinrichtung), - BACnet Advanced Application Controller (konfigurierbare Automationseinrichtung, Controller), - BACnet Application Specific Controller (Automationsgerät, anwendungsspezifische Steuer- und Regeleinheit), - BACnet Smart Actuator (netzwerkfähiges Schalt- und Stellgerät), - BACnet Smart Sensor (netzwerkfähiger Fühler) und - BACnet Gateway.

B.1 BACnet Operator Workstation (B-OWS) Die B-OWS ist die Bedienerschnittstelle zum BACnet System. Obwohl diese in erster Linie für die Bedienung des Systems benutzt wird, kann sie auch für Management- und Engineering- (Konfigurier-) Aufgaben eingesetzt werden, die ausserhalb der BACnet Norm liegen. Es ist nicht vorgesehen, dass die BACnet Operator Workstation direkt Steuerungs- und Regelungsaufgaben durchführt. Hieraus ergibt sich folgende Festlegung der Funktionen für die IOB: Datenaustausch - Fähigkeit zur Langzeitspeicherung von Daten (Historisierung), - Fähigkeit zur Präsentation von Daten (z.B. Berichte und Grafiken), - Fähigkeit zur Anzeige der Informationen (Zustände und Werte) von allen BACnet Objekttypen,

einschliesslich der geforderten und optionalen Objekt-Properties, - Fähigkeit zur Veränderung von Sollwerten und anderen Parametern. Alarm- und Ereignis-Management - Fähigkeit zur Darstellung von Ereignis- und Alarm-Informationen, - Fähigkeit zur Alarmquittierung durch den Bediener, - Fähigkeit zur Übersichtsprotokolle für Alarm- und Ereigniskategorien zu generieren, - Fähigkeit zur Anpassung von Alarmgrenzen, - Fähigkeit zur Anpassung der Informationsverteilung („Alarm Routing“). Zeitprogramme - Fähigkeit zur Modifizierung von Zeitprogrammen (Einträge für zeitabhängiges Schalten), - Fähigkeit zur Anzeige der Start und Stopp-Zeiten der zeitgesteuerten Anlagen Trend-Aufzeichnung - Fähigkeit zur Auswahl der Datenpunkte und Modifizierung der Parameter für Trend-Aufzeichnungen, - Fähigkeit zur Anzeige und Historisierung von Werten aus Trend-Aufzeichnungen. Device- und Netzwerk-Management - Anzeige von Informationen über den Status von jedem BACnet Device im GA-Netzwerk, - Anzeige von Informationen über jedes BACnet Objekt im GA-Netzwerk, - Fähigkeit, ein BACnet Device, das fehlerhafte Daten sendet, ruhig zu stellen, - Fähigkeit, Datum und Zeit im GA-Netzwerk zu synchronisieren, - Fähigkeit, ein entferntes BACnet Device zum Software-Neustart (Reset) zu veranlassen, - Fähigkeit, die Konfiguration von BACnet Devices zu sichern und zu laden, - Fähigkeit, Halb-router zum Auf- und Abbau von Verbindungen zu veranlassen, - Fähigkeit, zur Abfrage und zum Ändern der Konfiguration von Halb-routern und Routern

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 90

B.2 BACnet Building Controller (B-BC) Ein B-BC ist eine programmierbare Mehrzweck-Automationsstation die fähig ist ein Menge von verschiedenen Gebäudeautomations-, Steuer- Regel- und Optimierungsaufgaben wahrzunehmen. Das berechtigt die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit Informationen (Properties, Zustände und Werte) aller enthaltenen BACnet Objekttypen

bereitzustellen, - Fähigkeit Informationen (Properties, Zustände und Werte) der BACnet Objekttypen von anderen

Devices zu empfangen - Fähigkeit die Modifikation von einigen oder allen seiner BACnet Objekttypen durch andere Devices

zuzulassen Alarm- und Ereignis-Management - Fähigkeit zum Generieren von Alarm-/Ereignis- Benachrichtigungen und die Fähigkeit die Meldungen

an definierte Empfänger zu senden, - Fähigkeit zum Halten einer Liste von unquittierten Alarmen und Ereignissen, - Fähigkeit zum Generieren von Benachrichtigungen, dass eine Quittierung durchgeführt wurde und die

Fähigkeit diese Nachricht an definierte Empfänger zu senden, - Fähigkeit zur Anpassung der Alarm- und Ereignisparameter. Zeitprogramme - Fähigkeit zur zeitabhängigen Steuerung aller Arten von Ausgabefunktionen im eigenen Device und in

anderen BACnet Devices im GA-Netzwerk, Trend-Aufzeichnung - Fähigkeit zum Erfassen und Übertragen von Zeit/Wert-Paaren für Trend-Aufzeichnungen, Device- und Netzwerk-Management - Fähigkeit, Informationen über den Device-status zu geben, - Fähigkeit, Anfragen zu Informationen über jedes seiner BACnet Objekte zu beantworten, - Fähigkeit, auf Kommandos zur Kommunikationssteuerung zu reagieren, - Fähigkeit, die interne Uhr auf Anforderung zu synchronisieren, - Fähigkeit, einen Softwareneustart (Reset) auf Anforderung durchzuführen - Fähigkeit, seine Konfigurationsdaten über das GA-Netzwerk zu sichern (Upload) und

zurückzuspeichern (Download), - Fähigkeit Halb-router zum Auf- und Abbau von Verbindungen anzusteuern

B.3 BACnet Advanced Application Controller (B-AAC) Ein B-AAC ist eine konfigurierbare Automationseinrichtung mit limitierten Resourcen im Vergleich zum B-BC. Sie kann für spezielle Applikationen bestimmt sein und unterstützt die Implementierung vorgefertigter Programme. Hieraus ergibt sich die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit Informationen (Properties, Zustände und Werte) aller enthaltenen BACnet Objekttypen

bereitzustellen, - Fähigkeit die Modifikation von einigen oder allen seiner BACnet Objekttypen durch andere Devices

zuzulassen Alarm- und Ereignis-Management

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 91

- Fähigkeit zum Generieren von Alarm-/Ereignis- Benachrichtigungen in eingeschränktem Masse und

die Fähigkeit die Meldungen an definierte Empfänger zu senden, - Fähigkeit zum Reagieren auf Alarmquittierungen durch Bediener, - Fähigkeit zur Anpassung der Alarmparameter. Zeitprogramme - Fähigkeit zur zeitabhängigen Steuerung von Funktionen im eigenen Device, Trend-Aufzeichnung - Keine Anforderungen Device- und Netzwerk-Management - Fähigkeit, Anfragen über den Device-status zu beantworten, - Fähigkeit, Anfragen zu Informationen über jedes seiner BACnet Objekte zu beantworten, - Fähigkeit, auf Kommandos zur Kommunikationssteuerung zu reagieren, - Fähigkeit, die interne Uhr auf Anforderung zu synchronisieren, - Fähigkeit, einen Softwareneustart (Reset) auf Anforderung durchzuführen

B.4 BACnet Application Specific Controller (B-ASC) Ein B-ASC ist ein Automationsgerät als anwendungsspezifische Steuer- und Regeleinheit/Controller mit limitierten Resourcen im Vergleich zu einer B-AAC. Es ist für spezifische Anwendungen vorgesehen und enthält vom Hersteller implementierte Programme, es kann parametriert werden. Hieraus ergibt sich die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit Informationen (Properties, Zustände und Werte) aller enthaltenen BACnet Objekttypen

bereitzustellen, - Fähigkeit die Modifikation von einigen oder allen seiner BACnet Objekttypen durch andere Devices

zuzulassen Alarm- und Ereignis-Management - Keine Anforderungen Zeitprogramme - Keine Anforderungen Trend-Aufzeichnung - Keine Anforderungen Device- und Netzwerk-Management - Fähigkeit, Anfragen über den Device-status zu beantworten,

B.5 BACnet Smart Actuator (B-SA) Ein B-SA ist ein Feldgerät als netzwerkfähige Schalt- oder Stelleinrichtung. Hieraus ergibt sich die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit Informationen (Properties, Zustände und Werte) aller enthaltenen BACnet Objekttypen auf

Anforderung bereitzustellen, - Fähigkeit die Modifikation von einigen oder allen seiner BACnet Objekttypen durch andere Devices

zuzulassen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 92

Alarm- und Ereignis-Management - Keine Anforderungen Zeitprogramme - Keine Anforderungen Trend-Aufzeichnung - Keine Anforderungen Device- und Netzwerk-Management - Keine Anforderungen

B.6 BACnet Smart Sensor (B-SS) Ein B-SS ist ein Feldgerät als netzwerkfähiger Fühler. Hieraus ergibt sich die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit Informationen (Properties, Zustände und Werte) aller enthaltenen BACnet Objekttypen auf

Anforderung bereitzustellen, Alarm- und Ereignis-Management - Keine Anforderungen Zeitprogramme - Keine Anforderungen Trend-Aufzeichnung - Keine Anforderungen Device- und Netzwerk-Management - Keine Anforderungen

B.7 BACnet Gateway (B-GW) Ein B-GW ist ein Device für eine Bi-direktionale Umsetzung von Daten und Informationen zwischen BACnet Devices und Einrichtungen die ein anderes Kommunikationsprotokoll benutzen. Hieraus ergibt sich die Festlegung der folgenden Funktionen für die IOB: Datenaustausch - Fähigkeit, Informationen der ausgewählten Datenpunkte der anderen Seite den BACnet Devices so

zur Verfügung zu stellen, als ob die Informationen (Properties, Zustände und Werte) von BACnet Objekten erzeugt wurden,

- Fähigkeit, die Modifikation von Parametern und Werten der ausgewählten Datenpunkte der anderen Seite unter Benutzung der Standard BACnet Schreib-Services zu ermöglichen.

Alarm- und Ereignis-Management - Fähigkeit zum Generieren von Alarm-/Ereignis- Benachrichtigungen und die Fähigkeit die Meldungen

an definierte Empfänger auf beiden Seiten zu senden, - Fähigkeit zum Halten einer Liste von unquittierten Alarmen und Ereignissen, - Fähigkeit zum Generieren von Benachrichtigungen, dass eine Quittierung durchgeführt wurde und die

Fähigkeit diese Nachricht an definierte Empfänger auf beiden Seiten zu senden,

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 93

- Fähigkeit zur Anpassung der Alarm- und Ereignisparameter. Zeitprogramme - Fähigkeit zur zeitabhängigen Steuerung aller Arten von Ausgabefunktionen im eigenen Device und in

anderen Einrichtungen auf beiden Seiten. Trend-Aufzeichnung - Fähigkeit zum Erfassen und Übertragen von Zeit/Wert-Paaren für Trend-Aufzeichnungen, Device- und Netzwerk-Management - Fähigkeit, Anfragen über den Device-status zu beantworten, - Fähigkeit, Anfragen zu Informationen über jedes seiner BACnet Objekte zu beantworten, - Fähigkeit, auf Kommandos zur Kommunikationssteuerung zu reagieren, - Fähigkeit, die interne Uhr auf Anforderung zu synchronisieren, - Fähigkeit, einen Softwareneustart (Reset) auf Anforderung durchzuführen

B.8 IOB- Profile der Standard BACnet Devices Die folgenden Tabellen beschreiben welche BIBBs von jedem Device-type im jeweiligen IOB unterstützt werden müssen. Device-type

IOB B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GW Data Sharing DS-RP-A,B DS-RP-A,B DS-RP-B DS-RP-B DS-RP-B DS-RP-B DS-RP-B DS-RPM-A DS-RPM-A,B DS-RPM-B DS-WP-B DS-WP-B DS-RPM-B DS-WP-A DS-WP-A,B DS-WP-B DS-WP-B DS-WPM-A DS-WPM-B DS-WPM-B DS-WPM-B DS-COVU-A,B B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GW Alarm & Event Mgmt

AE-N-A AE-N-B AE-N-B AE-N-B

AE-ACK-A AE-ACK-B AE-ACK-B AE-ACK-B AE-ASUM-A A-ASUM-B AE-ASUM-B A-ASUM-B AE-ESUM-A AE-ESUM-B AE-ESUM-B B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GW Scheduling SCHED-A SCHED-B SCHED-B B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GW Trending T-VMT-A T-VMT-B T-VMT-B T-ATR-A T-ATR-B T-ATR-B B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GW Device & DM-DDB-A,B DM-DDB-A,B DM-DDB-B DM-DDB-B DM-DDB-B Network DM-DOB-A,B DM-DOB-A,B DM-DOB-B DM-DOB-B DM-DOB-B Mgmt DM-DCC-A DM-DCC-B DM-DCC-B DM-DCC-B DM-DCC-B DM-TS-A DM-TS-B

oder DM-UTC-B

DM-TS-B oder DM-UTC-B

DM-TS-B oder DM-UTC-B

DM-UTC-A DM-RD-A DM-RD-B DM-RD-B DM-RD-B DM-BR-A DM-BR-B NM-CE-A NM-CE-A

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 94

Anhang C Normung in Europa

C.1 Unterschiede Europa / USA Die im Vorwort genannten Unterschiede zwischen der original ANSI/ASHRAE-BACnet-Norm und den europäischen Experimentalnormen entstanden im Rahmen der Europäischen Normung bei CEN/TC 247 Automation und Management für die Technische Gebäudeausrüstung in der Working Group 4, da zu Beginn der europäischen Normungsarbeiten mehrere Protokolle den Einzug in die Normung zu erreichen versuchten. Ein wesentlicher Unterschied der aktuellen Dokumente in Europa zum ANSI/ASHRAE BACnet Standard 135-1995 bestand darin, dass in Europa vorerst so genannte Experimental- oder Vornormen, welche 3 bis maximal 5 Jahre bestehen dürfen, geschaffen wurden. BACnet ersetzt als DIN EN ISO 16484-5 ohne Ebenenzuordnung direkt die Experimentalnormen DIN EN V 1805-1:1997 (Managementebene) und ENV 13321-1:1998 (Automationsebene) Auch die weiteren ENVs für Systeme der Gebäudeautomation mussten nach ihrer maximalen „Laufzeit“ zurückgezogen werden. Andere Normprotokolle können auch als Teil des umfassenden Protokolls für Gebäudeautomation in einer eigenständigen Norm spezifiziert sein, z. B. ISO/IEC 8802-3 (CSMA/CD), EIA-709.1 (LonTalk) oder EN 50090 (EIB/KNX). Diese sind dann in der Weltnorm DIN EN ISO 16484-5 referenziert, (Anmerkung: FND als ENV 1805-2 wurde nach europaweiter Abstimmung im Jahr 2000 nach 5-jähr. Laufzeit zurückgezogen) Anders als die nun gültige DIN EN ISO 16484-5:2004 für BACnet, schränkten die europäischen Vornormen die Netzwerkoptionen für BACnet ein. Dieses Handbuch enthält als Leitfaden auch die Beschreibung dieser Netzwerkoptionen ARCNET und MS/TP.

C.3 Einschränkungen bei den europäischen Vor- bzw. Experimentalnormen Die Einschränkungen und die Ebenen der Europäischen Vornormen sind mit Herausgabe der Weltnorm DIN EN ISO 16484-5:2004 nicht mehr relevant. Mit der nationalen Einführung der GA-Weltnorm DIN EN ISO 16484 für Gebäudeautomation wurden die Netzwerk-Einschränkungen hinfällig, die Experimentalnormen sind zurückgezogen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 95

C.4 Die Struktur der GA-Normung in Europa, Stand 2004 Für die Gebäudeautomation ist das Technische Komitee TC 247 Automation und Management für die Technische Gebäudeausrüstung im Komitee für Europäische Normung (CEN) zuständig. Die Normierungsaktivitäten im Bereich Gebäudesystemtechnik erfolgen im Europäischen Komitee für Elektrotechnische Normung (CENELEC), CLC/TC 205 Elektrische Systemtechnik für Haus und Gebäude.

Report Mutual Observer ISO/TC 205 WG 3 Report Mutual Observer ISO/TC 205 WG 3 -- CEN/TC 247, Hans R. Kranz, Paris FR, CEN/TC 247, Hans R. Kranz, Paris FR, OctOct. 2006, . 2006, PgPg: : 1818

Struktur von CEN/TC247 im Sept. 2006Struktur von CEN/TC247 im Sept. 2006Struktur von CEN/TC247 im Sept. 2006

WG 1Controls

for HeatingSystems

WG 1Controls

for HeatingSystems

WG2 Individual

Zone/Room Control

WG2 Individual

Zone/Room Control

WG 4Open Data

Transmission

WG 4WG 4Open Data

Transmission

TC247Building

Automation,Controls, and

Building Management

TC247Building

Automation,Controls, and

Building Management

WG 5Building

ManagementIntegrated

Systems and Services

WG 5Building

ManagementIntegrated

Systems and Services

Secretary TC247Secretary TC247

C: D. DietrichTU Wien,

CC: P. FischerFH Dortmund

M. SchumacherCH

President U. WirthSiemens, CH

WG 6Integrated

Room Automation

WG 6Integrated

Room AutomationC: D. NaparSiemens, FR

CC: R. CyssauCOSTIC, FRPL: H.Kranz

WG 3Building

Automation and Control

Systems

WG 3WG 3Building

Automation and Control

SystemsC: K. Churches

T.A.C. UKPL: H.Kranz

C: ConvenorCC: Co-ConvenorPL: Project leader

Abb. C 4-1: Stuktur des CEN Technischen Komitees (TC247) für die Gebäudeautomation

CEN/TC 247 Build. Automation,

Controls and Building Mgt.

CEN/TC 247 Build. Automation,

Controls and Building Mgt. Euro

pean

Euro

pean

Nat

iona

lN

atio

nal

Nat

iona

lIn

tern

atio

nal

Inte

rnat

iona

l

ACR France AICAR Italy

BCG UK VDMA Germay

ACR France AICAR Italy

BCG UK VDMA Germay

Trade associations

EUBACEuropean Building

Automation and Controls Association

EUBACEuropean Building

Automation and Controls Association

Standardization organisations Government

CEN/TC 89, 156, 169, 228CLC/TC205

CEN/TC 89, 156, 169, 228CLC/TC205

National shadow groups organized by CEN Members active in CEN/TC247

e.g. AFNOR, BSI, DIN, DS, IBN, IRL, NSF, ON, SFS, SIS, SNV, UNI

National shadow groups organized by CEN Members active in CEN/TC247

e.g. AFNOR, BSI, DIN, DS, IBN, IRL, NSF, ON, SFS, SIS, SNV, UNI

ISO/TC205Building Environment

Design

ISO/TC205Building Environment

Design

VDI 3814SSPC135

WTO Members

EPD

Abb. C 4-2: Verbindungen der Komitees für die Gebäudeautomation

JWG 247-205 JWG 247-205

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 96

C.4 Grundgedanke des GAEB und Standardleistungsbuchs Der GAEB fördert den Einsatz der Datenverarbeitung im Bauwesen unter Berücksichtigung der gemeinsamen Sprache aller am Bau Beteiligten. Der GAEB orientiert sich im Allgemeinen an: - Freiwilligkeit bei der Mitarbeit, - Beteiligung aller interessierten Kreise durch paritätische Besetzung der Gremien, - Neutralität in Wort und Zahl, - einvernehmlichen Beschlüssen und bei der Textbearbeitung an:

den Normen der Allgemeinen Technischen Vertragsbedingungen für Bauleistungen (ATV) im Teil C der Vergabe- und Vertragsordnung für Bauleistungen (VOB),

- Produktneutralität, - Praxisnähe, (es werden nur gängige Bauleistungen aufgenommen), - Wirtschaftlichkeit, - Ausrichtung an den allgemein anerkannten Regeln der Technik und - Ausrichtung am allgemeinen Nutzen. Der GAEB schafft hiermit die Voraussetzungen für eine integrierte Datenverarbeitung bei der Durchführung von Baumaßnahmen. Die Schwerpunkte der GAEB-Arbeit liegen in der Erstellung und Überarbeitung von standardisierten Texten zur Beschreibung von Bauleistungen (Neubau und Instandhaltung), Regelwerken für den elektronischen Datenaustausch und den Aufbau des Leistungsverzeichnisses und Verfahrensbeschreibungen für die elektronische Bauabrechnung (GAEB-VB). Die standardisierten Texte sind im Standardleistungsbuch für das Bauwesen (STLB-Bau, STLB-BauZ) enthalten und ermöglichen die Aufstellung von Leistungsbeschreibungen im Sinne des § 9 VOB/A. Die Sammlung der standardisierten Texte deckt mit ihrer Variantenvielfalt das Baugeschehen vom Kleinauftrag bis zum Großbauvorhaben ab. Das Standardleistungsbuch für das Bauwesen wird vom GAEB in Verbindung mit dem Deutschen Vergabe- und Vertragsausschuss für Bauleistungen (DVA) aufgestellt und vom DIN Deutsches Institut für Normung e.V. herausgegeben. Die Regelungen für den elektronischen Datenaustausch und den Aufbau des Leistungsverzeichnisses und Verfahrensbeschreibungen sind Voraussetzungen für die automatisierte Vergabe und Abrechnung von Bauleistungen (AVA). Im GAEB sind die öffentlichen und privaten Auftraggeber, die Architekten und Ingenieure und die Bauwirtschaft durch ihre jeweiligen Spitzenorganisationen vertreten. Hierzu zählen z.B.: - Öffentliche Bauverwaltungen - Wohnungswirtschaft, - Bauabteilungen der Industrie, - Bau- und Baustoffwirtschaft, - Architekten- und Ingenieurverbände sowie die - Bundesverband Bausoftware e.V. Die für den GAEB tätigen Experten der Facharbeitskreise stellen unentgeltlich ihr Fachwissen zur allgemeinen Nutzanwendung zur Verfügung und garantieren somit die Neutralität und die Akzeptanz der Arbeitsergebnisse durch alle am Bau Beteiligten. Jedes Mitglied trägt die ihm aus der Mitarbeit entstehenden Aufwendungen selbst. Bedeutung: In vielen Planungsbüros wird die Wichtigkeit einer eindeutigen und erschöpfenden Leistungsbeschreibung immer noch nicht erkannt. In keiner Phase der Planung sind mehr Normen, Gesetze und Richtlinien zu beachten, als in der Ausschreibungsphase; und diese Regeln ändern sich ständig. Die Zeiten, in denen in ellenlangen Vorbemerkungen alles geregelt werden konnte, sind lange vorbei. Das war schon seit Einführung des AGB-Gesetzes im Jahre 1976 nicht mehr zulässig, nur hatte es sich in Planerkreisen nicht überall herumgesprochen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 97

Individuelle Beschreibungsarten und insbesondere eigene Wortschöpfungen bei LV-Gliederungen wie "Zusätzliche Allgemeine Vertragsbedingungen" oder "Besondere Technische Vertragsbedingungen" etc. sind ungeeignet, weil sie nicht mit der Nomenklatur der VOB übereinstimmen und im Falle von Widersprüchen nachrangig und damit regelmäßig unwirksam werden. Das Aufstellen einer zweckmäßigen. d.h. eindeutigen und erschöpfenden Leistungsbeschreibung setzt die Kenntnis der einschlägigen Vergabevorschriften voraus. Wer nicht weis, was neben der Teilleistungsbeschreibung noch anzugeben ist und wo es innerhalb der Vergabeunterlagen (§ 10 VOB/A) seinen Platz hat, dem mangelt es an fachlicher Qualifikation und der wird heutigen Anforderungen an sachkundiger Projektbearbeitung nicht gerecht. Schließlich wird mit dem Leistungsverzeichnis ein Bauvertrag begründet, der über Qualitäten, Kosten und Termine entscheidet. In der Leistungsbeschreibung wird nur ein Teil der Vertragsleistung beschrieben. Weitere Festlegungen werden in den einzelnen Vertragsbedingungen getroffen. Das sind gemäß § 10 VOB/A:

- Besondere Vertragsbedingungen (BVB)

- Zusätzliche Vertragsbedingungen (ZVB)

- Zusätzliche Technische Vertragsbedingungen (ZTV)

- Allgemeine Technische Vertragsbedingungen für Bauleistungen (VOB/C)

- Allgemeine Vertragsbedingungen für die Ausführung von Bauleistungen (VOB/B)

Die Besonderen Vertragsbedingungen (BVB) regeln die Erfordernisse des Einzelfalles, d.h. hier werden die Besonderheiten des speziellen Bauvorhabens festgelegt, z.B. Zufahrtsmöglichkeiten, vorhandene Medienanschlüsse, Beginn- und Fertigstellungstermin etc. Die Zusätzlichen Vertragsbedingungen (ZVB) sind für Auftraggeber vorgesehen, die ständig Bauleistungen vergeben, für die bei ihnen allgemein gegebenen Verhältnisse. Die Zusätzlichen Technischen Vertragsbedingungen (ZTV) sind ebenfalls für Auftraggeber vorgesehen, die ständig Bauleistungen vergeben. Im Straßen- und Tiefbau spielen ZTV eine Rolle, im Hochbau sind keine ZTV bekannt. Die Allgemeinen Technischen Vertragsbedingungen für Bauleistungen (VOB/C) sollen grundsätzlich unverändert bleiben. Sie dürfen von Auftraggebern, die ständig Bauleistungen vergeben, durch Zusätzlichen Technischen Vertragsbedingungen (ZTV) ergänzt werden. Der Beschreibungstext einer Teilleistung soll eindeutig und erschöpfend sein. Er muss kurz, prägnant und alle für die Preisbildung erforderlichen Angaben enthalten. Jede Floskel, Selbstverständlichkeit oder die Erwähnung der in der VOB geregelten Nebenleistungen ist zu vermeiden. Rahmenbedingungen wie Baustellengegebenheiten, Arbeitsabläufe, Ortsbestimmungen, Terminangaben etc. sind in den Vertragsbedingungen aufzuführen und gehören nicht in den Leistungstext. Im Leistungsverzeichnis ist die Leistung derart aufzugliedern, dass unter einer Ordnungszahl (Position) nur solche Leistungen aufgenommen werden, die nach ihrer technischen Beschaffenheit und für die Preisbildung als in sich gleichartig anzusehen sind (§9 Nr.9 VOB/A). Ziel einer effektiven Aufgliederung der zu beschreibenden Leistung ist die Bildung von Teilleistungspositionen mit größtmögliche Mengenansätzen. Große Mengenansätze führen erfahrungsgemäß zu günstigen Preisen und erreichen bei Mengenabweichungen seltener die 10-Prozentgrenze, bei der eine Preisanpassung vorgenommen werden muss (§ 2 VOB/B). Nicht jede Leistung lässt sich mit Texten aus dem Standardleistungsbuch beschreiben. Eine Untersuchung hat ergeben, dass etwa (fallbezogen) 86 Prozent mit dem STLB-Bau hätte beschrieben werden können. Das STLB-Bau setzt beim Aufsteller der Leistungsbeschreibung voraus, dass er über eine profunde Kenntnis des Vergabewesens verfügt und in der Lage ist, alle Anwendungsmöglichkeiten des Standardleistungsbuches auszuschöpfen. Der Aufsteller sollte daher so geschult werden, dass er in der Lage ist, mit den knappen, telegrammstilartigen Textfragmenten die Leistung im Sinne von §9 VOB/A eindeutig und erschöpfend zu beschreiben. Ihm muss bewusst werden, dass die Texte immer nur im Kontext mit den Vertragsbedingungen als Teil der Vergabeunterlagen wirken und dass scheinbar fehlende Angaben im STLB-Bau-Text in den Vertragsbedingungen allgemein enthalten oder dort im Einzelfall

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 98

projektbezogen zu ergänzen sind. Der unmittelbare Leistungstext lässt sich ergänzen durch einen Hinweis vor einer Position, wenn nur eine Position betroffen ist, oder durch Einzelbeschreibung, wenn der Umfang größer ist oder wenn mehrere Positionen einbezogen werden. Die Zeiten sind vorbei, in denen man in versteckten Klauseln den Leistungsumfang für den Kalkulator verschleiern konnte. Das Vergaberechtsänderungsgesetz (VgRÄG), eingeflossen als Teil 4 in das Gesetz gegen Wettbewerbsbeschränkung (GWB), fordert eine Transparenz in der Vergabe. Das bedeutet auch, dass die Leistung transparent zu beschreiben ist. Angebote auf der Grundlage von frei getexteten Leistungsbeschreibungen mit versteckten Klauseln können bei der Submission günstiger erscheinen. Sie werden aber im Laufe der Bauabwicklung durch Nachträge teurer. Firmen kennen ihre Rechte und wissen, dass Unklarheiten in Verträgen zu Lasten desjenigen gehen, der den Vertrag aufgestellt hat. Da auch kleinere Firmen, die über keine eigene Rechtsabteilung verfügen, sich von ihrer zuständige Innung Rechtsrat einholen können, setzt jede Firma in Zeiten knapper Aufträge ihren begründeten Anspruch durch. In solchen Fällen kann es im Ergebnis auch dazu führen, dass die Rangfolge der Bieter verschoben wird und der Zuschlag auf ein nicht wirtschaftliches Angebot erteilt worden ist. Das kann zu einem Haftungsfall für den LV-Aufsteller werden. Die Leistungsbeschreibung (LV) als Leistungsphase 6 ist in der Gebührenordnung mit 10 % des Gesamthonorars gut dotiert. Mit gut ausgebildeten Sachbearbeitern und mit einer guten, d.h. alle anfallenden Leistungen beinhaltende Leistungsbeschreibung wird die Grundlage geschaffen für eine wirtschaftliche Bauüberwachung, denn jedes Nachtragsangebot, das vermieden wird, bedeutet ersparten Aufwand. Der Aufwand für eine frei getextete Leistungsbeschreibung, die in Beschreibungsqualität und Rechtssicherheit dem heute zu fordernden Bearbeitungsstandard gemäß VOB entspricht, ist höher als eine Beschreibung mit STLB-Bau-Texten. Bei freien Texten hat der Bearbeiter einen zeitaufwendigen Abgleich mit dem aktuellen Normenstand und den Inhalten der Technischen Spezifikationen vorzunehmen, der im Standardleistungsbuch durch die Fachgremien erfolgen. Fazit Das Standardleistungsbuch hat hinsichtlich seiner Vollständigkeit noch einige Mängel, diese können jedoch in den Arbeitskreisen behoben werden.

Der Einsatz des Standardleistungsbuches ist zwar nur für den öffentlichen Auftraggeber zwingend vorgeschrieben, jeder Planer ist aber gut beraten, es auch für Projekte in der privaten oder gewerblichen Wirtschaft einzusetzen. Ein vergleichbar sachorientiertes und neutrales Werk, das von so vielen Baufachleuten getragen wird und für sich zu Recht in Anspruch nimmt, die gemeinsame Sprache am Bau wieder zu geben, existiert sonst nicht. Im Rahmen der ICIS (International Construction Information Society) gleichen ca. 20 führenden Staaten

ihre Bau-Ausschreibungssysteme ab. Das deutsche GAEB STLB-Bau hat sich dabei als das wegweisende

und fortschrittlichste System erwiesen.

Mitwirkung am STLB-Bau 070 „Gebäudeautomation“

Derzeit werden Texte für BACnet LVs erarbeitet. Da auch im AMEV (öffentliche Hand) eine Richtlinie für

BACnet-Ausschreibungen erarbeitet wird, müssen die Arbeiten aufeinander abgestimmt werden.

Im GAEB AK 070 können Interessierte jederzeit mitwirken, die jeweils 2-tägigen Sitzungen finden 2 mal

jährlich statt. Interessenten melden sich bei Hans R. Kranz ([email protected]).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 99

C.5 Einführungsverordnung des STLB-Bau

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 100

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 101

GAEB im Internet Aktuelle Informationen stehen auf der Homepage des GAEB unter www.gaeb.de. Hier werden u. a. Neuerungen zu STLB-Bau, STLB-BauZ und zum Datenaustausch GAEB DA 2000 angezeigt. Die vorgegebenen Beiblätter und die Übersicht aller zitierten Normen stehen zur Verfügung. Häufig gestellte Fragen und Antworten zur GAEB-Arbeit stehen unter der Rubrik "Infos". Bei www.beuth.de kann man mit dem Suchwort „STLB-Bau“ eine Demo-CD mit allen Leistungsbereichen (zur Freischaltung) und einem freien "Test-Leistungsbereich" (99) und Informationen aus der GAEB Homepage kostenlos bestellen. Aus der GAEB – CD-ROM: Sollten sich Kombinationen als nicht richtig herausstellen oder kalkulationsrelevante Angaben fehlen, kann im Anwenderprogramm der STLB-Bau-Text zum freien Text umgewandelt, ergänzt bzw. geändert werden.

Anhang D Beiblätter zum LV (Beispiele: GA-FL, HW, Netzwerk)

Beiblatt D 1 - Beispiel GA-Systemaufbau - Das Muster für den GA-Systemaufbau finden Sie auf unter http://www.gaeb.de/LBanhang.html

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 102

1) Dauerbefehl: Z.B. 0,I,II=2 BA 3) Nur gemeinsame, kommunikative Datenpunkte 6) Stellausgabe: Z.B. 3-Punkt = 2 x 2-PunktImpulsbefehl: Z.B. 0,I,II=3 BA von Fremdsystemen für interoperable Funktionen 7) Pro Eingangs-Benutzeradresse

Anhang A (normativ) Stellbefehl: Z.B. Zu-0-Auf=2 BA 4) Pro Eingangs-Benutzeradresse zum a) Zusammenfassen, 8) Z.B. Gerätestatus, Zeitschalttab., Sicherheitspkt., Regler, Datei (EN ISO 16484-5) Pulsweitenmod.=1 BA b) Verzögern und c) Unterdrücken von Meldungen 9) Falls erforderlich sind bei gemeinsamen (shared) Datenpunkten die Funktionen

2) Aktiv oder passiv 5) Pro Ausgangs-Benutzeradresse im Client mit "A" und die im Server mit "B" zu kennzeichnen (siehe BIBBs)

Gewerk: Ein- / Ausgabefunktionen Verarbeitungsfunktionen Management- Bedien-Physikalisch Gemeinsam 3)9) Überwachen Steuern Regeln Rechnen / Optimieren funktionen funktionen

Zeile

Nr.

Anlage

Bin

äre

Aus

gabe

Sch

alte

n / S

telle

n 1)

Ana

loge

Aus

gabe

Ste

llen

Bin

äre

Ein

gabe

Mel

den

Bin

äre

Ein

gabe

Zäh

len

Ana

loge

Ein

gabe

Mes

sen

2)

Bin

ärer

Aus

gabe

wer

t, Sc

halte

n

Ana

loge

r Aus

gabe

wer

t, S

telle

n/So

llwer

t

Bin

ärer

Ein

gabe

wer

t, Zu

stan

d

Zäh

lwer

tein

gabe

Ana

loge

r Ein

gabe

wer

t, M

esse

n

Gre

nzw

ert f

est

Gre

nzw

ert g

leite

nd B

etrie

bsst

unde

n-E

rfass

ung

Ere

igni

szäh

lung

Bef

ehls

ausf

ührk

ontro

lle M

eldu

ngsb

earb

eitu

ng 4

) A

nlag

enst

euer

ung

Mot

orst

euer

ung

Um

scha

ltung

5)

Fol

gest

euer

ung

5) S

iche

rhei

ts-/

Fros

tsch

utzs

teue

rung

P-R

egel

ung

PI /

PID

-Reg

elun

g S

ollw

ertfü

hrun

g / -

kenn

linie

Ste

llaus

gabe

ste

tig S

tella

usga

be 2

-Pun

kt 6

) S

tella

usga

be P

ulsw

eite

nmod

ulat

ion

Beg

renz

ung

Sol

lwer

t / S

tellg

össe

Par

amet

erum

scha

ltung

h,x

gef

ührte

Stra

tegi

e 7)

Arit

hmet

isch

e B

erec

hnun

g 7)

Ere

igni

sabh

ängi

ges

Sch

alte

n Z

eita

bhän

gige

s Sc

halte

n G

leite

ndes

Ein

- / A

ussc

halte

n Z

yklis

ches

Sch

alte

n N

acht

kühl

betri

eb R

aum

tem

pera

turb

egre

nzun

g E

nerg

ierü

ckge

win

nung

7)

Net

zers

atzb

etrie

b N

etzw

iede

rkeh

rpro

gram

m H

öchs

tlast

begr

enzu

ng T

arifa

bhän

gige

s Sc

halte

n

Ein

-/Aus

gabe

Obj

ektty

p 9)

Kom

plex

er O

bjek

ttyp

8) 9

)

Ere

igni

s-La

ngze

itspe

iche

rung

His

toris

ieru

ng in

Dat

enba

nk

Gra

fik /

Anla

genb

ild D

ynam

isch

e E

inbl

endu

ng E

reig

nis-

Anw

eisu

ngst

ext

Nac

hric

ht a

n ex

tern

e S

telle

ANMERKUNGDefinition der Funktionen gemäss

VDI 3814-1 : 2005(DIN EN ISO 16484-3).

Kennzeichne projektspezifische Beschreibung nicht genormter Funktionen in

der Bemerkungsspalte der Datenpunkt-Zeile z.B. mit

Zeile Nr., Abschnitt Nr., Spalte Nr., Beiblatt/Beschreibung Nr.

BIBBs =BACnet Interoperability Building Blocks,

siehe DIN EN ISO 16484-5

Datenpunkt Abschnitt 1 2 3 4 5 6 7 8 9 Z. B. DP-Name mit Nr. Spalte 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 6 1 2 3 4 5 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 1 2 3 4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

Summe Funktionen

Ausgabedatum JJ-MM-TT Name Geprüft Planersteller: Projekt: Informationsschwerpunkt: Datei: Rev. 1 [Tabelle_ISO-GA-FL-Vorlage-1_050513.xls]

Rev. 2 Rev. 3

© 1996-2005 ISO/TC205_CEN/TC247_VDI-TGA_GAEB070

DIN EN ISO 16484-3

Zeichnungs-Nr.:

GA-Funktionsliste

Steuerungsbeschr. Nr.:

Bemerkungen

von: Blatt Nr.1

Beiblatt D 1 - Beispiel GA-Funktionsliste

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 103

1) Dauerbefehl: Z.B. 0,I,II=2 BA 3) Nur gemeinsame, kommunikative Datenpunkte 6) Stellausgabe: Z.B. 3-Punkt = 2 x 2-PunktImpulsbefehl: Z.B. 0,I,II=3 BA von Fremdsystemen für interoperable Funktionen 7) Pro Eingangs-Benutzeradresse

Annex A (normativ) Stellbefehl: Z.B. Zu-0-Auf=2 BA 4) Pro Eingangs-Benutzeradresse zum a) Zusammenfassen, 8) Z.B. Gerätestatus, Zeitschalttab., Sicherheitspkt., Regler, Datei (EN ISO 16484-5) Pulsweitenmod.=1 BA b) Verzögern und c) Unterdrücken von Meldungen 9) Falls erforderlich sind bei gemeinsamen (shared) Datenpunkten die Funktionen

2) Aktiv oder passiv 5) Pro Ausgangs-Benutzeradresse im Client mit "A" und die im Server mit "B" zu kennzeichnen (siehe BIBBs)

Gewerk: Ein- / Ausgabefunktionen Verarbeitungsfunktionen Management- Bedien-Physikalisch Gemeinsam 3)9) Überwachen Steuern Regeln Rechnen / Optimieren funktionen funktionen

Zeile

Nr.

Anlage

Bin

äre

Aus

gabe

Sch

alte

n / S

telle

n 1)

Ana

loge

Aus

gabe

Ste

llen

Bin

äre

Ein

gabe

Mel

den

Bin

äre

Ein

gabe

Zäh

len

Ana

loge

Ein

gabe

Mes

sen

2)

Bin

ärer

Aus

gabe

wer

t, S

chal

ten

Ana

loge

r Aus

gabe

wer

t, S

telle

n/S

ollw

ert

Bin

ärer

Ein

gabe

wer

t, Zu

stan

d

Zäh

lwer

tein

gabe

Ana

loge

r Ein

gabe

wer

t, M

esse

n G

renz

wer

t fes

t G

renz

wer

t gle

itend

Bet

riebs

stun

den-

Erfa

ssun

g E

reig

nisz

ählu

ng B

efeh

lsau

sfüh

rkon

trolle

Mel

dung

sbea

rbei

tung

4)

Anl

agen

steu

erun

g M

otor

steu

erun

g U

msc

haltu

ng 5

) F

olge

steu

erun

g 5)

Sic

herh

eits

-/ Fr

osts

chut

zste

ueru

ng P

-Reg

elun

g P

I / P

ID-R

egel

ung

Sol

lwer

tführ

ung

/ -ke

nnlin

ie S

tella

usga

be s

tetig

Ste

llaus

gabe

2-P

unkt

6)

Ste

llaus

gabe

Pul

swei

tenm

odul

atio

n B

egre

nzun

g S

ollw

ert /

Ste

llgös

se P

aram

eter

umsc

haltu

ng h

,x g

efüh

rte S

trate

gie

7) A

rithm

etis

che

Ber

echn

ung

7) E

reig

nisa

bhän

gige

s S

chal

ten

Zei

tabh

ängi

ges

Sch

alte

n G

leite

ndes

Ein

- / A

ussc

halte

n Z

yklis

ches

Sch

alte

n N

acht

kühl

betri

eb R

aum

tem

pera

turb

egre

nzun

g E

nerg

ierü

ckge

win

nung

7)

Net

zers

atzb

etrie

b N

etzw

iede

rkeh

rpro

gram

m H

öchs

tlast

begr

enzu

ng T

arifa

bhän

gige

s S

chal

ten

Ein

-/Aus

gabe

Obj

ektty

p 9)

Kom

plex

e O

bjek

ttyp

8) 9

)

Ere

igni

s-La

ngze

itspe

iche

rung

His

toris

ieru

ng in

Dat

enba

nk

Gra

fik /

Anl

agen

bild

Dyn

amis

che

Ein

blen

dung

Ere

igni

s-A

nwei

sung

stex

t N

achr

icht

an

exte

rne

Ste

lle

ANMERKUNGDefinition der Funktionen gemäss

VDI 3814-1 : 2005(DIN EN ISO 16484-3).

Kennzeichne projektspezifische Beschreibung nicht genormter Funktionen in

der Bemerkungsspalte der Datenpunkt-Zeile z.B. mit

Zeile Nr., Abschnitt Nr., Spalte Nr., Beiblatt/Beschreibung Nr.

BIBBs =BACnet Interoperability Building Blocks,

siehe DIN EN ISO 16484-5

Datenpunkt Abschnitt 1 2 3 4 5 6 7 8 9 Z. B. DP-Name mit Nr. Spalte 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 6 1 2 3 4 5 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 1 2 3 4

Übertrag:

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

Summe Funktionen

Ausgabedatum JJ-MM-TT Name Geprüft Planersteller: Projekt: Informationsschwerpunkt: Datei: Rev. 1 [Tabelle_ISO-GA-FL-Vorlage-2_050513.xls]

Rev. 2 Rev. 3

© 1996-2005 ISO/TC205_CEN/TC247_VDI-TGA_GAEB070

Zeichnungs-Nr.: Steuerungsbeschr. Nr.:

EN ISO 16484-3

GA-Funktionsliste

Blatt Nr. von:

Bemerkungen

Beiblatt D 1 - Beispiel GA-Funktionsliste (fortgesetzt)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 104

Beiblatt D 2 – Adress-Struktur

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 105

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 106

Beiblatt D 3 - Netzwerkdarstellung

Beiblatt D 4 - Bieterangaben zum Netzwerk

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 107

Beiblatt D 5 - Bieterangaben zur Automations-Hardware

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 108

Anhang E Gebäudeautomation auf der GAEB CD :

E.1 Leistungsbereich 070 - GAEB - XML Version

Abb: E-1: Einstieg in den LB 070 – Auswahl aus den Leistungsbereichen des STLB-Bau Mit Informationsbutton für besondere Hinweise für den Aufsteller des Leistungsverzeichnisses

Abb: E-2: Einstieg in den LB 070 – Darstellung der Struktur

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 109

GAEB-Hinweis bei Auswahl des Leistungsbereiches 070 Gebäudeautomation im STLB-Bau: Anmerkung: Die Lieferungen und Leistungen für Gebäudeautomation sind aufgeteilt in: 1. Programme Die Leistungsmerkmale der Programme entsprechen der EN ISO 16484. Da die Software für Bedien- und Managementfunktionen je nach Hersteller unterschiedlich aufgebaut ist, werden die angebotenen Leistungsmerkmale vom Hersteller abgefragt. Software jeglicher Art unterliegt dem Urheberrecht. Die Nutzungsbedingungen sind spätestens bei der Vergabe festzulegen. 2. GA-Funktionen Funktionen gemäß DIN EN ISO 16484-3, zur Massenermittlung dargestellt in Funktionsliste GA, Beiblatt 070-5, pro Informationsschwerpunkt insbesondere bei Anwendung einer Datenschnittstelleneinheit. Die Funktionen enthalten betriebsfertige Leistungen der technischen Bearbeitung wie technische Klärung und Bearbeitung. Eingabe von Adressen, Benutzeradressen, Klartext, Kennlinien, Messbereichen, Einheiten, Parametern, Programmteilen, Programmen, funktionsinterne Merker und Verknüpfungen, Test, Inbetriebnahme, Einregulierung und Ersteinweisung der Anlagenbetreiber sowie die geforderte System- und Anlagen-Dokumentation. Anmerkung: Den GA-Funktionen ist grundsätzlich die "Standardbeschreibung GA-Funktionen" voranzustellen. 3. Hardware Zur Hardware gehören die Grundsoftware wie das Betriebssystem und die Treiber für die Komponenten. Da die Hardware aller Systemkomponenten je nach Hersteller unterschiedlich aufgebaut ist, werden die angebotenen Leistungsmerkmale vom Hersteller abgefragt. entweder im LV-Text oder in Beiblatt 070-4_AutomationsHardware_Bieterang.xls und Beiblatt 070-11_Netzwerkkomponenten_Bieterang.xls. 4. Datenschnittstelleneinheiten (DSE) DSE ermöglichen die kommunikative Einbindung von Fremdgeräten/-systemen. Die zugehörigen kommunikativen Ein-/Ausgabe-, Verarbeitungs-, Management- und Bedienfunktionen sind in einer gesonderten GA-Funktionsliste festzulegen und auszuschreiben, ggf. mit Angabe von Client und Server. Bei Kommunikation mit Fremdsystemen über das BACnet-Protokoll nach DIN EN ISO 16484-5 sind ebenfalls DSE mit Angabe der Interoperabilitätsbereiche (BIBBs) festzulegen. Die angebotenen Leistungsmerkmale werden vom Hersteller abgefragt. 5. Feldgeräte, Schaltschränke sowie MSR-/Kommunikationsverbindungen 6. Besondere Leistungen Besondere Leistungen der Gebäudeautomation sind Dienstleistungen, die nicht durch die Funktionen nach VDI 3814 abgedeckt werden und keine Nebenleistungen im Sinne der VOB sind. Zu den besonderen Leistungen gehören z. B. Funktionsprüfungen fremder Lieferungen und Leistungen (insbesondere bei Datenschnittstelleneinheiten). Siehe DIN 18386, Kapitel 4.2. 7. Beiblätter Zu diesem Leistungsbereich stehen Anhänge in Form von Vordrucken, Skizzen etc. zur Verfügung. Diese finden Sie auf der STLB-Bau-CD unter dem Menüpunkt "Anhänge zu einzelnen Leistungsbereichen" bzw. unter http://www.gaeb.de/LBanhang.html. Anhänge Zu diesem Leistungsbereich stehen Anhänge in Form von Vordrucken, Skizzen etc. zur Verfügung. Diese finden Sie auf der STLB-Bau-CD unter dem Menüpunkt "Anhänge zu einzelnen Leistungsbereichen" bzw. unter http://www.gaeb.de/LBanhang.html.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 110

Abb: E-3: Aufruf Positionstexte für „Besondere Leistungen“, Bedienung und Management (Wird ab 10/04 in die allgemeinen „Besonderen GA-Leistungen“ integriert)

Abb: E-4: Aufruf Positionstexte für Zusätzliche Leistungen (VOB: „Besondere Leistungen“).

Abb: E-5: Ein Positionstext für „Besondere Leistungen“ zur Übergabe an ein AVA-Programm

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 111

Abb: E-6: Standardbeschreibungen Standardbeschreibungen sind grundsätzlich vor die zutreffenden Leistungspositionen zu setzen, sie legen Merkmale fest, die für alle folgenden Leistungen dieser Art gleichermassen gelten.

Abb: E-7: Auswahl der Standardbeschreibungen Beispieltexte siehe: E.2.1. GA-System Standardbeschreibungen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 112

Abb: E-8: Auswahl Positionstexte für Software der Bedienfunktionen mit Darstellung aller Beschreibungsmerkmale

Abb: E-9: Entstehung des Positionstextes für die Softwarelizenz Managementsystem (ohne Darstellung aller Beschreibungsmerkmale)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 113

Abb: E-10: Entstehung des Positionstextes für die Softwarelizenz Bediensystem

Abb: E-11: Entstehung des Positionstextes für eine Datenschnittstelleneinheit (z. B. Gateway)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 114

E.2 Beispiele aus Texten des STLB-Bau 070 ANMERKUNG: Auf der GAEB CD-ROM haben alle Teilleistungsgruppen weitere Merkmale zur Auswahl. Die Beispieltexte werden wiedergegeben mit Erlaubnis des DIN Deutsches Institut für Normung e.V.

Maßgebend für das Anwenden der GAEB STLB-Bau CD, der GAEB DA XML CD der ist die jeweils

neueste Ausgabe des GAEB-Datenaustausches, der als CD mit dem Titel "GAEB DA XML, Organisation

des Austausches von Informationen über die Durchführung von Baumaßnahmen" oder der GAEB STLB-

Bau CD bei dem Beuth Verlag GmbH, Burggrafenstraße 6, 10787 Berlin, erhältlich ist.

E.2.1. GA-System Standardbeschreibungen Den Teilleistungen (Positionen) ist, wenn vorgesehen, grundsätzlich die Standardbeschreibung voranzustellen, diese gilt dann für alle nachfolgenden Positionen dieser Art. TLG: Standardbeschreibungen Gebäudeautomationssysteme STLB-Bau 10/2003 070 TB Gefordert sind die Einrichtungen, Programme und Leistungen gemäß VDI 3814 Blatt 2 für Managements-, Automations- und Ein-/Ausgabefunktionen, mit genormtem Kommunikationsprotokoll in und zwischen den einzelnen Funktionsebenen, Hersteller/Typ BIETERANGABE Einzelbeschreibungs-Nr REFERENZ ZUR DEN GEFORDERTEN BESCHREIBUNGEN STLB-Bau 10/2003 070 TA Das Gebäudeautomationssystem ist dargestellt im Beiblatt-Nr 0815 SYSTEMSTRUKTUR, BEIBLATT D1. physikalische und kommunikative Ein-/Ausgabefunktionen, Anzahl .50.000. Bedienplätze im eigenen Netzwerk, Anzahl 5. Bedienplätze im systemfremden Netzwerk mit gleichzeitigem Zugriff, Anzahl 2. mit Datenverarbeitungseinrichtung im Gebäude/in den Gebäuden Verwaltung und Energiezentrale. Einzelbeschreibungs-Nr 4711

STLB-Bau 10/2003 070 TA Anforderungen an das Gebäudeautomationssystem im Endausbau: physikalische und kommunikative Ein-/Ausgabefunktionen, Anzahl 100.000. Bedienplätze im eigenen Netzwerk, Anzahl 10. Bedienplätze in systemfremden Netzwerk mit gleichzeitigem Zugriff, Anzahl 5. Die Betriebsparameter Soll- und Grenzwerte, Stellung von Stellgliedern, Ein-/Ausschaltzeiten, Regelparameter, Anfangswerte der Betriebsstundenzählung und Umschaltzeiten, sind über eine Bedieneinheit und/oder über die Managementebene einstellbar, der Zugriff ist in mehreren Zugriffsbereichen und in verschiedenen Zugriffsebenen möglich, mit Datenverarbeitungseinrichtung im Gebäude/in den Gebäuden Erweiterungsbau. Einzelbeschreibungs-Nr 0815.

STLB-Bau 10/2003 070 Die alphanumerische Benutzeradressen-Struktur ist wie folgt aufgebaut: Ortskennzeichnung 3 Stellen, Anlagenart 3 Stellen, Anlagen-Nummer 3 Stellen, Funktion 3 Stellen, laufende Nummerierung 2 Stellen, mit 4 zusätzlichen Trennzeichen, sie gilt für Bedien-, Management-, Verarbeitungs-, physikalische und kommunikative Ein-/Ausgabefunktionen. Adressierungssystem gemäß Einzelbeschreibung, Einzelbeschreibungs-Nr Beiblatt 070-3. ODER Adressstruktur gemäß GA-Funktionsliste, GA-Funktionsliste 0815-Kellerzentrale, 4711-Dachzentrale.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 115

STLB-Bau 10/2003 070 Reaktionszeiten im systemeigenen Netzwerk, für das Melden und Anzeigen eines Ereignisses auf Managementeinrichtungen, nach Erfassen der Ein-/Ausgabefunktionen, max. 8 Sekunden, zwischen dem Absetzen eines Schaltbefehls von einer Managementeinrichtung und dem Beginn der Ausführung der Ein-/Ausgabefunktionen max. 8 Sekunden, für das Anzeigen eines neuen Bildes und das Einblenden von bis zu 30 aktuellen Informationen max. 30 Sekunden.

STLB-Bau 10/2003 070 Angaben zur Datum- und Uhrzeitsynchronisation: Datum- und Uhrzeitsynchronisation aller Systemkomponenten mit systeminterner Funkuhr, mind. einmal täglich und nach Netzwiederkehr, Umschaltung Sommer-/Winterzeit erfolgt automatisch, Anzeige der Zeit in Stunden, Minuten und Sekunden, Wochentage werden dargestellt, Ereignissen und Werten wird in Automationseinrichtungen der Zeitstempel hinzugefügt, die Zeitauflösung beträgt max. 1 s. Alternativer Zusatz: , Ereignissen und Werten aus dem Bereich Schaltanlagen wird in Automationseinrichtungen der Zeitstempel hinzugefügt, die Zeitauflösung beträgt max. 0,1 s. STLB-Bau 10/2003 070 Angaben zur Netzart und Stromversorgung: TNC-System DIN VDE 0100-300, als Sicherheitstromversorgung SV DIN VDE 0100-710, Netzspannung 400 V AC, Umgebungstemperatur 0 bis 45 Grad C, relative Umgebungsfeuchte 5 bis 90 % (nicht kondensierend), Störfestigkeit DIN EN 61000-6-2, Störaussendung DIN EN 61000-6-3. STLB-Bau 10/2003 070 Bei Netzausfall wird die Spannung für Managementeinrichtungen unterbrechungsfrei über die USV-Anlage bereitgestellt. Bei wiederkehrender Netzspannung gehen die Managementeinrichtungen automatisch ohne Neueingabe von Programmen, Parametern oder Handeingriff wieder in Betrieb. Die Betriebszustände aller Automationseinrichtungen und ihrer Datenschnittstelleneinheiten sowie Prozessabbilder bzw. Prozesszustände werden automatisch abgefragt. STLB-Bau 10/2003 070 Systemselbstüberwachung, auf Ausfall der Datenverarbeitungseinrichtung, auf Störung der Kommunikation, auf Störung von Programmabläufen, zur Ansteuerung einer Einrichtung für optische und akustische Meldung der Störung.

E.2.2 Teilleistungsgruppe (Position) Software für Bedienfunktionen (auf der CD-ROM hat diese Teilleistungsgruppe weitere Merkmale zur Auswahl) STLB-Bau 10/2003 070 TA psch:………… Software für das Bedienen und Beobachten pro Bedieneinrichtung einschl. der erforderlichen Programme für die Systemverwaltung sowie das Verarbeiten von Prozessinformationen. Die Programme beinhalten die Rechte zur bestimmungsgemässen Nutzung gemäss Lizenzschein. Anwendungs- und nutzerspezifische Parametrierungen der Programme sind an dieser Stelle nicht enthalten, sie sind Bestandteil der Funktionen oder besondere Leistungen. Programme der Systemverwaltung bestehend aus: Systemselbstüberwachung und -diagnose zum Anzeigen der Auslastung von CPU, Hauptspeicher, Massenspeicher und Netzwerk(en) sowie von Störungen der Hardware-Einrichtungen, der Kommunikation und von Programmabläufen, - Systemaktivitätenliste mit Archivierungssystem zum Aufzeichnen aller Aktivitäten der Selbstüberwachung und Diagnose in einer Systemdatei und im Archivierungssystem, mit Möglichkeit der Anzeige des Dateiinhaltes auf Bildschirm oder Protokollierung auf Drucker, - Benutzeradressen-System zur Verwaltung der vorgegebenen Benutzeradressen-Struktur,

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 116

- Systemzugriffsschutz zum Schutz gegen unbefugte Bedienung und zur Steuerung der zugelassenen Bedienfunktionen pro Bediener, wobei eine höhere Zugriffsebene die Rechte aller niedrigeren Ebenen einschliesst, - Ein-/Mehrplatzbedienung sowohl zur direkten Ansteuerung eines einzelnen Bedienplatzes als auch zur Ansteuerung örtlich verteilter Bedienplätze, - Bedieneraktivitätenliste zum Aufzeichnen aller Bedienaktivitäten in einer Systemdatei, wie z. B. An- und Abmelden, Befehlsausgaben, Quittierungen, Parameteränderungen, Änderungen des Zugriffsschutzes, mit Möglichkeit der Anzeige des Dateiinhaltes auf Bildschirm oder Protokollierung auf Drucker. - Datenarchivierung zur dauerhaften Sicherung von Systemdateien und von Informationen, die mit der Historisierung gespeichert wurden, die Daten werden auf ein externes Speichermedium übertragen und können von dort zurückgelesen werden. - Bedien- und Beobachtungsprogramme bestehend aus: - Ereignisbehandlung mit Eintrag in die Ereignisliste bei Zustandswechsel, Zuordnung von Priorität, Zeitstempel, Quittiererfordernis und Quittiererkennung, Benutzeradresse, Texten und Ausgabekategorien, - Druckersteuerung für Zeilendruck zur Ausgabe von einzelnen Meldungen auf Endlospapier für die Ereignisprotokollierung, zur Ausgabe von Anlagenbildern, Listen, Zeitreihendiagrammen und formatierten Berichten sowie Ausgabe von Bildschirmkopien, Druck von Farbgrafiken, Steuerung der Druckqualität, Druckausgabe ereignis-, zeit-, und bedienergesteuert, - Ausgabegeräte-Auswahlstrategie zur Zuordnung von Ausgabeaufträgen zu Bildschirmgeräten und Druckern nach Kategorien, mit Erkennung und Meldung von fehlerhaften Ausgabegeräten und Umleitung von Ausgabeaufträgen im Fehlerfall sowie mit zeit- und ereignisgesteuerter Umleitung, - Darstellung pro Benutzeradresse auf Ausgabegeräten mit folgenden zusätzlichen Angaben: Datum und Zeit sowie Zustand oder Wert und Einheit mit erläuterndem alphanumerischen Klartext, mit optischer Visualisierung durch Farbumschlag, Blinken oder bewegter Animation auf Sichtgeräten, mit Kennzeichnung Zustand/Wert als aktuell/alt, Grenzwerte mit erläuternden Texten, Unterscheidung von Meldungen nach Kategorien, Kennzeichnung von Stör- und Alarmmeldungen als quittiert/unquittiert, mit quittierbarer akustischer Signalisierung, Alarm in allen Bedienzuständen sichtbar im Sichtgeräte-Vordergrund, - Ereignis-Anweisungstexte zur Ausgabe auf Bildschirm/Drucker im Anschluss an eine kommende Ereignismeldung entsprechend der Zuordnung von Anweisungstexten zu Benutzeradressen, Anweisungstexte, Anzahl ....................................................... mit Zeichen, Anzahl ....................................................... - Dialogsteuerung passend zur Hardware der Bedienstation(en) und der Zugriffsberechtigung des Bedieners, - mit Benutzeroberfläche alphanumerisch und grafisch, - mit Informationsanwahl und -darstellung unabhängig von Benutzeradressen-Struktur: grafisch, - Sprache Benutzeroberfläche: deutsch, - Bedienung mit Programmteilen für Anwahl und Anzeige bzw. Ausgabe für die geforderten Funktionen, - Quittierung von Ereignismeldungen und akustischen Alarmen, - Protokollprogramme bestehend aus: - Ereignisprotokollierung zur Ausgabe von Zustandsänderungen auf Bildschirmen und Druckern gemäss den Bedien- und Beobachtungsprogrammen "Ereignisbehandlung", "Darstellung pro Benutzeradresse" und "Ereignis-Anweisungstexte", - Übersichtsprotokollierung zur Ausgabe von Protokollen auf Bildschirmen/Druckern nach Anforderung durch Bediener oder durch Programme (zeit-/ereignisgesteuert), auswählbar nach verschiedenen Kriterien, z. B. Gebäuden/Räumen, Anlagenarten, einzelnen Anlagen, Informationsarten (z. B. Messwertübersicht, Zählwertübersicht), Informationszuständen (z. B. Störungsübersicht, Wartungsübersicht), die Auswahl eines Übersichtsprotokolls erfolgt z. B. durch Überschreiben von Teilen der Benutzeradresse mit Platzhalterzeichen (wild cards), - Trendprotokollierung zur Ausgabe von ausgewählten Informationen über einen längeren Zeitraum mit vorwählbaren Registrierintervall auf Bildschirm/Drucker nach Anforderung durch einen Bediener in Form von vordefinierbaren Listen unter Angabe von z. B. Adresse, Zeit, Zustand/Wert, als grafische Darstellung von Werten in Zeitreihen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 117

(Liniendiagramm), - Anzahl Adressen: 4 gleichzeitig darstellbar, - Direkthilfe sowohl zur kontextorientierten Erläuterung aller Funktionen und Bedienabläufe des Systems als auch mit Stichwort-Suchfunktion (Index), mit Ausgabe auf Bildschirm/Drucker.

E.2.3 Teilleistungsgruppe (Position) Automationseinrichtung (Hardware) STLB-Bau 10/2003 070 TA TB ST:… Automationseinrichtung, für den Informationsschwerpunkt Kältezentrale Standort Verwaltungsgebäude Keller gemäss GA-Funktionsliste, Beiblatt 070-5, Blatt-Nr 0815 und Verfahrensfliessschema/Funktionsbeschreibung-Nr 4711 Netzart Allgemeine Stromversorgung AV, Netzspannung 230 V AC, Umgebungstemperatur 0 bis 45 Grad C, relative Umgebungsfeuchte 5 bis 90 % (nicht kondensierend), für Einbau in Schaltschrank, mit Peer-to-Peer Kommunikation, einschl. Anschluss an digitales Wählnetz, mit erweiterter Spannungsversorgung zur Aufrechterhaltung der Funktion der Automationseinrichtung, für mind. 0,25 h, einschl. Anzahl und Art physikalischer Ein-/Ausgänge passend zu den Funktionen, zusätzlich sind folgende physikalische Ein-/Ausgänge als Reserve enthalten, Binär-Eingänge (BE) Anzahl …………………………….20 vom Bieter einzutragen Binär-Ausgänge (BA) Anzahl ……………………………...5 vom Bieter einzutragen Analog-Eingänge (AE) Anzahl ……………………………10 vom Bieter einzutragen Analog-Ausgänge (AA) Anzahl …………………………….5 vom Bieter einzutragen Zähl-Eingänge (ZE) Anzahl ………………………………...5 vom Bieter einzutragen Reserveein-/-ausgänge betriebsfertig für die Eingabe von Programmen, Bezeichnung, Typ, Stückpreis und Anzahl der Hardwarekomponenten je Informationsschwerpunkt siehe Beiblatt 070-4, Blatt-Nr ………………………………………….BIETERANGABE in BEIBLATT GEM. D-5. Hersteller/Typ ................................................S-KLASSE / 300 (Bieterangabe) vom Bieter einzutragen. zugehörige Funktionen werden gesondert vergütet. Anmerkung: Den Funktionen ist die Position Standardbeschreibung Funktionen voranzustellen.

E.2.4 Standardbeschreibung GA-Funktionen (Engineeringleistungen) STLB-Bau 10/2003 070 Standardbeschreibung GA-Funktionen gemäß DIN EN ISO 16484-3 (VDI 3814 Blatt 1:2004), Massenermittlung dargestellt in GA-Funktionsliste, Beiblatt 070-1, für die Erfassung, Aufbereitung und Ausgabe von Informationen. Sie enthalten Dienstleistungen, wie technische Klärung und Bearbeitung. Eingabe von Adressen, Benutzeradressen, Klartext, Kennlinien, Messbereichen, Einheiten, Parametern, Programmteilen, Programmen, funktionsinterne Merker und Verknüpfungen, Test, Inbetriebnahme, Einregulierung und Ersteinweisung der Anlagenbetreiber, Dokumentation.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 118

E.2.5 LV-Beispiel: GA-Funktionen nach VDI 3814-Standard (Engineeringleistungen) 10 Gewerk 1

10 10 Titel 1

10 10 10 0.000 St

STLB-Bau 10/2003 070 Physikalische Ein-/Ausgabefunktion, Binäre Ausgabe Schalten/Stellen.

10 10 20 0.000 St

STLB-Bau 10/2003 070 Physikalische Ein-/Ausgabefunktion, Analoge Eingabe Messen, mit Überwachung auf Geberstörung.

10 10 30 0.000 St

STLB-Bau 10/2003 070 Kommunikative Ein-/Ausgabefunktion, Eingabe Zählwert.

10 10 40 0.000 St

STLB-Bau 10/2003 070 Kommunikative Ein-/Ausgabefunktion, Ausgabe Stellen/Sollwert.

10 10 50 0.000 St

STLB-Bau 10/2003 070

Verarbeitungsfunktion Überwachen, für Grenzwert gleitend, pro Überprüfung eines physikalischen, kommunikativen oder berechneten Messwertes, auf die Einhaltung einer vorzugebenden gleitenden Grenze.

10 10 60 0.000 St

STLB-Bau 10/2003 070 Verarbeitungsfunktion Überwachen, für Befehlsausführkontrolle, pro Benutzeradresse.

10 10 70 0.000 St

STLB-Bau 10/2003 070

Verarbeitungsfunktion Überwachen, für Meldungsbearbeitung, zum Zusammenfassen, Verzögern und Unterdrücken von Meldungen, pro Benutzeradresse.

10 10 80 0.000 St

STLB-Bau 10/2003 070 Verarbeitungsfunktion Steuern, für Anlagensteuerung.

10 10 90 0.000 St

STLB-Bau 10/2003 070 Managementfunktion, Kommunikation Ein-/Ausgabefunktion.

10 10 100 0.000 St

STLB-Bau 10/2003 070 Managementfunktion, Kommunikation Block/Datei.

10 10 110 0.000 St

STLB-Bau 10/2003 070 Managementfunktion, Historisierung in Datenbank.

10 10 120 0.000 St

STLB-Bau 10/2003 070 Bedienfunktion, Grafik/Anlagenbild.

10 10 130 0.000 St

STLB-Bau 10/2003 070 Bedienfunktion, Dynamische Einblendung.

10 10 140 0.000 St

STLB-Bau 10/2003 070 Bedienfunktion, Ereignis-Anweisungstext, bis 256 Zeichen.

Dadurch, dass die Funktionen im Detail in der DIN EN ISO 16484-3 (bzw. VDI 3814-1:2004) definiert sind, werden die Leistungsverzeichnisse auf diese Art bedeutend dünner als bisher.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 119

E.2.6 Teilleistungsgruppe (Position) BACnet-Datenschnittstelleneinheit (z. B. Gateway) STLB-Bau 10/2003 070 TA TB St:…. Datenschnittstelleneinheit (DSE) zum Datenaustausch mit Automationseinrichtungen anderer Fabrikate, Typen und Systeme, bestehend aus: Hardware, Spannungsversorgung, geräte- und mediumspezifischen Anschlüssen und Verbindern, Kommunikations- und Treiber-Software zur Umsetzung der Protokolle und der zu übertragenden Adressen, Daten und Texte einschl. Koordination mit dem DSE-Kommunikationspartner, sowie Erstellung der Dokumentation, Einbindung in die Automationseinrichtung, Automationseinrichtung Kellergeschoss gemäss BACnet-Protokoll DIN EN ISO 16484-5, Übertragungsmedium und ggf. Protokollvariante gemäss Einzelbeschreibung, Einzelbeschreibungs-Nr NISTIR 6392 und gemäss GA-Funktionsliste für die DSE, GA-Funktionsliste 4711 Anzahl der max. umsetzbaren Funktionen ……………….BIETERANGABE vom Bieter einzutragen zugehörige kommunikative Ein-/Ausgabe-, Verarbeitungs- und Bedienfunktionen werden gesondert vergütet, DSE einschl. anteiliger Leistungen wie Pflichtenheft-Erstellung, Werks-/Labortest und Prüfdokumentation, einschl. Nachweis der Normenkonformität, Hersteller/Typ .................................................................BIETERANGABE vom Bieter einzutragen

E.2.7 Teilleistungsgruppe (Position) Datenschnittstelleneinheit zur Brandmeldeanlage TLG: Schnittstellen zu anderen Fabrikaten, Typen, Systemen STLB-Bau 10/2003 070 TA TB psch:… Datenschnittstelleneinheit (DSE) zum Datenaustausch mit Brandmeldesystem, bestehend aus: Hardware, Spannungsversorgung, geräte- und mediumspezifischen Anschlüssen und Verbindern, Kommunikations- und Treiber-Software zur Umsetzung der Protokolle und der zu übertragenden Adressen, Daten und Texte einschl. Koordination mit dem DSE-Kommunikationspartner, sowie Erstellung der Dokumentation, einschl. temporärer Speicherung des aktuellen Prozessabbildes der zu übertragenden Datenpunkte, Einbindung in die Managementeinrichtung, Managementeinrichtung Sicherheitszentrale gemäß BACnet-Protokoll, DIN EN ISO 16484-5, Übertragungsmedium und ggf. Protokollvariante gemäß Einzelbeschreibung, Einzelbeschreibungs-Nr 4711-2, NISTIR 6392. gemäß GA-Funktionsliste für die DSE, GA-Funktionsliste 0815-Brand. Anzahl der max. umsetzbaren Funktionen 1000. zugehörige kommunikative Ein-/Ausgabe-, Verarbeitungs- und Bedienfunktionen werden gesondert vergütet, DSE einschl. anteiliger Leistungen wie Pflichtenheft-Erstellung, Werks-/Labortest und Prüfdokumentation sowie Prüfzeugnisse, einschl. Nachweis der Normenkonformität mit Zertifikat durch eine autorisierte Prüfstelle, in Datenverarbeitungseinrichtung eingebaut, Hersteller/Typ BIETERANGABE. vom Bieter einzutragen.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 120

E.3 Freie Textbeispiele für Standardbeschreibungen BACnet Gesamtkonzeption Die Gesamtkonzeption des herstellerneutralen GA-Netzwerks lässt es zu, dass über die in der Norm DIN EN ISO 16484-5 festgelegten Objekte und Dienste hinaus noch herstellerspezifische Funktionen bereitgestellt werden. Diese können nicht von allen Herstellern im Markt unterstützt werden. Diese herstellereigenen Funktionen werden über die Minimalanforderungen der Norm hinaus nur von Einrichtungen eines Herstellers unterstützt, ohne dass sie die Gesamtfunktion des BACnet-Netzwerks beeinträchtigen. Sie dienen der Differenzierung der Geräte untereinander und erhöhen die Gesamtfunktion. Der Bieter muss nachweisen, dass er die geforderten Objekte und Dienste nach Norm DIN EN ISO 16484-2004 erbringen kann. Die Möglichkeit, eigene, proprietäre BACnet-Objekte und -Properties zu entwickeln darf nicht dazu führen, dass wesentliche Funktionen in einer vom Standard abweichenden Form realisiert werden, die das Zusammenwirken von Komponenten verschiedener Hersteller verhindert oder erschwert. Insbesondere sind die für die ausgeschriebenen Datenpunkte geforderten Objekte in vollem Umfang zu unterstützen. Dies ist durch die Konformitätserklärung PICS nachzuweisen. Sind zum Zeitpunkt der Auftragsvergabe neue Anhänge zur BACnet Norm gültig, erklärt der Bieter verbindlich, die neuen Funktionen im Rahmen einer Nachbeauftragung zu implementieren sowie seine Konformitätserklärung PICS hierfür bereit zu erstellen. "Native BACnet" Eine Definition von "native BACnet" als Systemeigenschaft ist normativ nicht festgelegt, sollte dennoch ein solches „Leistungsmerkmal“ gefordert werden, muss der Ausschreibende prüfbare Kriterien festlegen, die der Bieter nachweist. Zum Beispiel: Standardbeschreibung für Forderung von „native“ BACnet (den weiteren Positionen für die Hardware voranzustellen oder zur Standardbeschreibung des GA-Systems hinzufügen) Gefordert ist ein GA-System, dessen Komponenten die Merkmale eines "native" BACnet-Systems aufweisen. Anforderungen: a) Native BACnet betrifft Einrichtungen oder Knoten mit Kommunikation nach DIN EN ISO 16484-5 als einprogrammierte und immer verfügbare Grundeigenschaft; b) Zur Erzeugung der BACnet-Kommunikationsfähigkeit ist keine zusätzliche Hardware und kein zusätzlicher Dienstleistungsaufwand notwendig; (der Engineering-Aufwand für die GA-Funktionen wird getrennt vergütet). c) Alle gem. LV geforderten Objekttypen (nach DIN EN ISO 16484-5) sind verfügbar und zusammen mit den dazugehörigen BACnet-Diensten und Merkmalen gem. dem PICS des Herstellers unterstützt und zertifiziert; d) Zur Kommunikation mit Nicht-native-BACnet-Einrichtungen ist ein physikalisches oder virtuelles Gateway erforderlich, das in einem Device integriert sein darf. Beschreibung der "native" BACnet-Leistungsmerkmale im Beiblatt "PICS": (Beispiel) PICS Produkt „OGISED Typ XP 0815“, Beiblatt zum Angebot Nr. 4711…………………….. (vom Bieter einzutragen)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 121

BACnet Konformität allgemein BACnet legt Interoperabilitätsbereiche (IOB) fest die funktionale Beschreibung der Konformität mit der Norm DIN EN ISO 16484-5. Die Interoperabilitätsbausteine (BIBBs) in der Norm legen Dienste, unterschieden nach Client (A) und Server (B) für die spezifizierten BACnet-Device-types fest. Die Festlegungen sind nach den IOB gegliedert: 1. Für den BACnet IOB Datenaustausch, DS (Data Sharing) sind zu unterstützende BIBBs z.B.: > DS-RP-B - Read Property > DS-WP-B - Write Property > DS-COV-B - Bedienung von COV Alle entsprechenden Device-Typen (von Management- bis Automationseinrichtungen) unterstützen die zur Anzeige und Bedienung erforderlichen BACnet-Objekte, Properties und Dienste, z.B.: > Querkommunikation zwischen Automationsstationen (peer to peer) > Darstellung auf lokalen Bedieneinheiten > Darstellung auf Bedienstationen in Managementsystemen > Datenverwendung in Managementeinrichtungen Das angebotene System stellt alle zur Anzeige und Bedienung notwendigen Daten bereit. Das (native) BACnet-System unterstützt grundsätzlich und direkt alle im LV geforderten Objekt-Properties gem. Festlegung nach DIN EN ISO 16484, insbesondere: > Hauptwerte aller physikalischen und kommunikativen Datenpunkte, > Benutzeradresse mit mindestens 32 (60) Zeichen, > Datenpunktbeschreibung (Klartext) mit mindestens 32 Zeichen, frei editierbar, > Werte der Überwachungs- und Verarbeitungsfunktionen, > Zustandstexte, frei definierbar, für alle Binäinformationen (E/A), > Alarm- und Warngrenzen für AE, Z) > Betriebstundenzähler, > Schaltwechselzähler, > Regler und Regelparameter incl. Sollwerte, > Parameter der Anlagen- und Motorsteuerung, Eine Automationseinrichtung ist in der Lage, mindestens 800 BACnet-Objekte gleichzeitig zur Kommunikation und Anzeige bereitzustellen. 2. Für den BACnet IOB Alarm- und Ereignismanagement, AE (Alarm and Event Management) sind zu unterstützende BIBBs z.B.: > AE-N-B - Alarmmeldung auslösen > AE-ACK-B - Quittierung annehmen > AE-ASUM-B - Alarmübersicht senden Alle entsprechenden Device-Typen (von Management- bis Automationseinrichtungen) unterstützen die für Alarm- und Ereignismanagement erforderlichen BACnet-Objekte, Properties und Dienste, z.B.: > Austausch und die Verteilung von Ereignissen und Alarmen im System. Das System ist in der Lage, nach Vorgaben des Projektes Alarme an mehrere Bedieneinrichtungen und Managementsysteme zu verteilen und darzustellen, > Bedienen von Alarmen, > Erzeugen von Alarmprotokollen, > Einstellungen für Alarmempfänger, Alarmgrenzen, Alarmunterdrückung zu kommunizieren, 2. Für den BACnet IOB Device- und Netzwerkmanagement , DM (Device and Network Management) sind zu unterstützende BIBBs z.B.: > DM-TS-B - Zeitsynchronisierung annehmen, > DM-DDB-B - Dynamische Device Verbindung (Einrichtungen im Netzwerk suchen), > DM-DOB-B - Dynamische Objekt Verbindung (Objekte im Netzwerk suchen). Alle entsprechenden Device-Typen (von Management- bis Automationseinrichtungen) unterstützen die für Device- und Netzwerkmanagement erforderlichen BACnet-Objekte, Properties und Dienste, z.B.: > Geräte- und Netzwerkeigenschaften über BACnet abzufragen und zu verändern, > Zeitsynchronisierung angeschlossener Einrichtungen

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 122

> Lebenszeichenüberwachung angeschlossener Einrichtungen. Die Konformität ist vom Hersteller zu erklären und mit einem PICS (Protocol Implementation Conformance Statement, nach DIN EN ISO 16484-5, Annex A, zu belegen. Dieses PICS ist vollständig ausgefüllt und gibt Auskunft über die normenkonforme Unterstützung der > Device-Profile, > Dienste, jeweils als Client und Server, > Standard BACnet-Objekte, > Standard- und optionale Properties aller BACnet-Objekte, > Herstellerspezifischen BACnet-Objekte und Erweiterungen der Properties, > Unterstützte physikalische Medien, > Spezifische Einstellparameter, wie Datenraten, zulässige Wertebereiche, > Unterstützte Zeichensätze (europäisch und/oder amerikanisch). Das PICS pro BACnet Device-type ermöglicht die Abklärung des Grades der Interoperabilität. PICS als Beschreibung der BACnet-Fähigkeit liegen dem Angebot bei. Eventuelle produktbedingte Limitierungen und Einschränkungen des BACnet-Standards sind detailliert zu beschreiben. Angebote ohne ein vollständiges und nachprüfbares PICS für alle angebotenen Systemkomponenten (Management, Automation) werden aus der Wertung ausgeschlossen. (Alternativ) Angebote ohne ein vollständiges und zertifiziertes PICS für alle angebotenen Systemkomponenten (Management, Automation) werden aus der Wertung ausgeschlossen. Die Konformität zu BACnet, nachgewiesen durch ein ausgefülltes PICS, ist Voraussetzung für ein optimales Zusammenwirken im Sinne interoperabler Funktionen. Durch Einhaltung der Device-Profile nach Norm sind die verschiedenen Systemkomponenten inhaltlich und sinngemäss aufeinander abgestimmt. BACnet-Komponenten arbeiten nur zusammen, wenn sie über aufeinander abgestimmte (komplementäre) Dienste und geeignete Objekte verfügen. Es ist Aufgabe des Bieters, durch Abgleich und Überprüfung der Übereinstimmung der PICS sicherzustellen, das sein System die geforderte Funktionalität liefert – auch bei Verbindung mit einem Fremdsystem.

E.4 Freie Textbeispiele für spezielle BACnet Einrichtungen BACnet-Router BACnet-Router zum Medienwechsel BACnet/LON <-> BACnet/Ethernet/IP Leistungsmerkmale: - Verteilung globaler Broadcasts auf das BACnet-Internetzwerk (über IP-Router hinweg) - Datensicherung bei Stromausfall für Konfigurationsparameter/Statistikdaten - Integrierte Schnittstellen 1 BACnet/LonTalk (Clause 11), EIA-709.1, TP/FT-10A, 78kBit/s, 1 BACnet/IP (Annex J), auf Ethernet, 10BaseT, IEEE 802.3, kompatibel, 10Mbit/s, RJ45, 1 lokales Bediengerät oder Inbetriebnahme-/Servicetool, Steckbar RJ45 - LEDs für Betriebs-, Sende- und Empfang - Montage: DIN-Schiene oder Platte Abmessungen in mm (HxBxT) …………… vom Bieter Einzutragen - Prozessor und Arbeitsspeicher ………….. vom Bieter Einzutragen ….(z.B: 32 Bit Prozessor, 2MB Flash + 1MB RAM)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 123

WEB-Server WEB-Server für Automationsstationen mit nativer Kommunikation BACnet in Kompakt-Bauweise, Leistungsmerkmale: - Bedienen und Beobachten mit passwortgeschütztem Zugriff systemweit auf: > Anlagen- und Betriebszustände, > Soll- und Istwerte, > Stör- , Alarm- und Wartungsmeldungen > Quittierung der Meldungen mit Selbsthaltung > Alarm- und Ereignisliste > Zeitschaltprogramme mit Kalender - Alarmierung über SMS und Email - Up-/Download der Dateien für Anlagengrafiken - Grafische Heizkurvendarstellung und Trend-Aufzeichnung - BACnet Device Profil: B-OWS für folgende IOB: DS, AE, SCHED, T, DM, - Schnittstellen: 1 BACnet/LonTalk, TP/FT-10A, 78 kBit/s 1 Ethernet/IP, 10BaseT, IEEE 802.3, 10Mbit/s, RJ45 1 Modemschnittstelle EIA RS232 Abmessungen in mm (HxBxT) vom Bieter einzutragen …………………… Anhang F BACnet Checkliste für interoperable Gebäudeautomation Ziel dieses Anhangs ist es eine Checkliste zur Verfügung zu stellen, die sicherstellt, dass die

wichtigsten Elemente, die für ein interoperables BACnet GA-System nötig sind. Die Punkte sollen

bedacht und spezifiziert werden.

Dieser Anhang wurde aus dem Hauptdokument herausgelöst. Er wiederholt die in den Kapiteln

gegebenen Anweisungen ohne den jeweils einleitenden Text.

Bei Aufstellung des Leistungsverzeichnisses mit dem GAEB STLB 070 dient dieses bereits automatisch als Checkliste für eine systemneutrale Ausschreibung der Gebäudeautomation mit den in Deutschland üblichen Worten und nach DIN EN ISO 16484 sowie für das Ausschreibungsverfahren nach VOB.

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 124

Checkliste neutrales GA-Leistungsverzeichnis für Interoperabilität Nr. Aktivität Check Schritt 1

A Ermitteln der benötigten physikalischen Datenpunkte – die Feldgeräte und Antriebe aus dem Automationsschema und der Funktionsbeschreibung je Anlage. Daraus ergeben sich die physikalischen E/A

1 Erstellung der Automationsschemata aus den Anlagenschemata (VDI 3814-1:2005, Bsp. 3814-4)

2 Festlegung der Betriebsarten der Anlage 3 Erstellung der Steuerlogik mittels Zustandsgraph (falls erforderlich) VDI 3814-6

(demnächst)

4 Eintragen der Datenpunkte in die GA-Funktionsliste (VDI 3814-1 bzw. ISO 16484-3) B Ermitteln der benötigten Automationsfunktionen

1 Ein-/Ausgabe- Kommunikationsfunktionen für „gemeinsame“ (shared) Datenpunkte (Integration auf Automationsebene)

2 Überwachungsfunktionen (z.B. Grenzwerte) 3 Steuerungsfunktionen (z.B. Motorsteuerung) 4 Regelungsfunktionen (z.B. Kaskadenregler) 5 Rechen- und Optimierungsfunktionen 6 Ergänzung der GA-Funktionsliste für Funktionsdokumentation und für die

Massenermittlung

C Ermitteln der benötigten Management- und Bedienfunktionen

1 Managementfunktionen (z.B. History) 2 Bedienfunktionen (Anlagenbild u. Einblendungen) 3 Management-Kommunikationsfunktionen (Integration für Bedienung oder

Managementebene)

4 Ergänzung der GA-Funktionsliste für Funktions-Dokumentation (wichtigster Vertragsbestandteil) und für die Massenermittlung

D Festlegung der Vorgaben für die strukturierte Verwendung von Objektnamen und Datenpunktadressen, an die sich jeder Lieferant innerhalb von verbundenen GA-Systemen halten muss (Object_Name) Siehe BACnet-Leitfaden und GAEB Beiblätter

1 Objektnamen = Datenpunktadressen sollen so lang wie im Projekt nötig, aber so kurz wie möglich sein (Beispiel VDI 3814-1:2005)

2 Festlegung, dass die Objektnamen an allen (Bedien-) Stellen im System zur Verfügung stehen, um eine einheitliche Kennzeichnung zu erreichen; Projektbeschreibung und LV-Anlage (GAEB / VDI Formblatt „Adress-Struktur“)

3 Festlegung, dass jedes BACnet-Objekt über eine Objektbeschreibung verfügt Im Objekt-Property „Description“ Festlegung in System-Standardbeschreibung („Vorbemerkung“)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 125

Nr. Aktivität Check Schritt 2 E Anforderungen für die Erstinstallation.

Festlegung der Interoperabilitätsbereiche:

Aus bisher aufgestellten GA-Funktionslisten gehen die erforderlichen Interoperabilitätsbereiche hervor, welche auf das Projekt zutreffen:

Festlegung aller benötigten Dienste anhand der BIBBs-Liste (in der Norm oder im Leitfaden), ob dieser Dienst als Client / Nutzer / Anforderer (Klasse A), oder als Server / Datenquelle / Bereithalter (Klasse B) im BACnet-Device vorhanden sein muss

1 Datenaustausch - DS

Festlegung der analogen, binären und digitalen Werte, welche über das jeweilige Netzwerk für oder von Fremdsystemen zur Verfügung stehen sollen; mit Darstellungsart und Skalierung

a Anwendung für Darstellung in: a,1 Grafiken a,2 Tabellen (Berichte), (ggf. für Trendaufzeichnung, Ereignisaufzeichnung) a,3 Für Historisierung von Werten b Anwendung für Anlagenbedienung: b,1 Sollwert- und Parameteränderungen b,2 Überwachung b,3 Aufträge („commands“/ früher „Befehle“) c Festlegung der Aktualisierungs- und Aufzeichnungsintervalle c,1 Festlegung, dass alle Zustände der BACnet-Objekt-Properties (z. B. „Eigenschaften“)

lesbar sind und dargestellt werden, Werte (values) mit SI-Einheiten

c,2 Festlegung, dass für die Übertragung von Wertänderungen der sogenannte COV-Mechanismus (Change-of-Value) verwendet wird; (System-Standardbeschreibung)

c,3 Festlegung, dass Bediener den Schwellenwert (COV-Inkrement) durch Schreibzugriff verändern können; (System-Standardbeschreibung)

c,4 Festlegung, dass bei Binär- und mehrstufigen Objekten die Properties zur Übertragung von Zustandstexten unterstützt werden; (System-Standardbeschreibung - ist eigentlich ansonsten „Stand der Technik“ - Forderung bei BACnet-Systemen jedoch erforderlich)

d Festlegung von "globalen Objekten" die allen BACnet- Einrichtungen zur Verfügung stehen müssen wie z.B. die Aussentemperatur; (GA-Funktionsliste „shared points“ - gemeinsame Datenpunkte)

d,1 Festlegung der benötigten Sollwerte als Bedienfunktion d,2 Festlegung der erforderlichen Parametermodifikationen als Bedienfunktion d,3 Festlegung der schreibbaren Properties für die Regler Objekte

(Loop-Object); Standardbeschreibung für Systemsoftware und GA-FL für Massenermittlung

e Festlegung der erforderlichen Peer-To-Peer (oder Quer-) Kommunikation Datenaustausch zwischen (GA-Funktionsliste „Verarbeitungsfunktionen“)

e,1 Kommunikation zwischen "fremden" Automationsstationen ohne Mitwirkung einer „Leittechnik“- oder Bedienereingriff (aus GA-FL "Verarbeitungsfunktionen")

f Festlegung der Managementfunktionen "Langzeitspeicherung" und "Historisierung"

f,1 Festlegung der Anzahl von Funktionen für die Speicherung (nach VDI-3814-Standard) f,2 Festlegung der Aufzeichnungsintervalle (z.B. Anzahl Werte / Std. für

Langzeitaufzeichnung oder History in Datenbank); (GA-FL: Managementfunktion „Ereignislangzeitspeicherung“ und Beschreibung)

f,3 Festlegung der Wege, mit denen aufgezeichnete Werte gesichert (archiviert) werden können, z.B. mit Bandlaufwerk, CDROM); (Beschreibung für Systemhard- und Software, z.B. GAEB 070)

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 126

Nr. Aktivität Checkf,4 Festlegung, dass autorisierte Bediener die Aufzeichnungsdauer und -Intervalle von

Datenpunkten verändern können, für die Historydaten aufgezeichnet werden; (GA-FL und Systemsoftwarebeschreibung)

2 Alarm- und Ereignismanagement - AE

Festlegung, nach welchen Kategorien und wie die Ereignis- oder Alarmmeldungen im System verteilt werden (Standardbeschreibung zur Systemsoftware) - Kennzeichnung in GA-FL

a Festlegung, wie Alarme dargestellt werden sollen b Festlegung, dass die Alarmerkennung für ein Ereignis bereits als Funktion in den

Automationseinrichtungen stattfindet, falls dies den Gegebenheiten der Anlage entspricht (GA-FL: Überwachungsfunktionen)

c Festlegung, dass eine Alarmquittierung verwendet wird und wie Alarmquittierungen dargestellt werden, (GA-FL: Verarbeitungsfunktion „Sicherheitssteuerung“, System-Standardbeschreibung)

d Festlegung, dass zu jedem Zeitpunkt eine Alarmübersicht zur Verfügung stehen muss (Systemsoftware Standardbeschreibung, z.B. GAEB 070)

e Festlegung, dass Alarmgrenzen veränderbar sind, falls dies erforderlich ist, (GA-FL: Bedienfunktionen)

f Festlegung von Meldungsklassen und Alarmpriorisierung (Standardbeschreibung für Systemsoftware - siehe BACnet-Leitfaden)

g Festlegung der Eingriffe des Bedieners in die Alarmerkennung (Detektierung), z.B. Abschalten von Grenzen als Bedienfunktion in der GA-FL.

3 Zeitplan - Sched

Festlegung der benötigten Zeitplanprogramme (GA-FL: Verarbeitungsfunktion „Zeitplan“; Beschreibung der Systemsoftware - GAEB 070)

a Festlegung, dass der Bediener auf Zeitschaltpläne Einsicht hat (Darstellung) b Festlegung, dass der Bediener auf Zeitschaltpläne Zugriff hat (Bedienung) c Festlegung der Anzahl der mind. möglichen Einträge;

(LV-Beschreibung für das System)

d Festlegung der Anzahl der benötigten Einträge; (GA-FL Einträge für Massenermittlung) 4 Trendaufzeichnung - T

Der IOB Trend bezieht sich auf eine Onlinefunktion, die vom Bediener aufgerufen werden sollte, (Standardbeschreibung zur Systemsoftware). Im Sonderfall können erforderliche Dienstleistungen für eine Trendaufzeichnung wie bei IOB DS mit der Managementfunktion "Langzeitspeicherung" gefordert werden. (GA-FL: Kommunikative Managementfunktion; mit Kennzeichnung in Bemerkungsspalte)

a Festlegung der Anzahl von Datenpunkten für die Trendaufzeichnung 5 Device- und Netzwerkmanagement – DM a Festlegung, dass der operative Status jeder BACnet-Einrichtung zu jeder Zeit angezeigt

werden kann; (Standardbeschreibung zur Systemsoftware)

b Festlegung, dass der Bediener jederzeit alle Properties von jedem BACnet-Objekt abfragen kann (Standardbeschreibung zur Systemsoftware)

c Festlegung, dass Geräte abgeschalten werden können, die fehlerhafte Daten senden; Standardbeschreibung zur Systemsoftware und BIBB: DM-DCC-A/B (DeviceCommunicationControl)

d Festlegung, dass Uhrzeitsynchronisation über das Netzwerk erfolgt; Beschreibung zur Systemsoftware (GAEB 070) und BIBB: DM-TS-B (TimeSynchronization), oder DM-UTC-A/B (UTCTimeSynchronization)

e Festlegung, dass BACnet-Devices (Einrichtungen) ferngesteuert neu gestartet werden

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 127

Nr. Aktivität Check

können, falls erforderlich; (Standardbeschreibung zur Systemsoftware und BIBB: DM-R-A/B (Restart)

f Festlegung, dass die Datensicherung und Datenrücksicherung für Devices über das Netzwerk durchgeführt werden kann (Backup/Restore); Standardbeschreibung zur Systemsoftware und BIBB: DM-BR-A/B (Backup and Restore)

g Festlegung bei RS232-Verbindungen (Halbrouter), dass Bediener ein Kommando für den Aufbau und Abbau von Verbindungen zwischen den angeschlossenen Netzwerken ausführen können; Beschreibung der Systemsoftware, BIBB: DM-CE-A/B (Connection Establishment)

h Festlegung, dass Bediener in der Lage sein müssen, Parameter von Routern zu beeinflussen; Beschreibung der Router-Hard- und Systemsoftware, BIBB: DM-RC-A/B (Router Configuration)

i Festlegung, dass Router die Routing-Informationen automatisch ermitteln und untereinander austauschen; Beschreibung der Routerhardware

j Festlegung, dass für die technische Bearbeitung (Engineering) oder für Diagnosezwecke das Property „Out-of-Service“ von Analog-, Binär-, Digital-, Regler- und Programm-Objekten „schreibbar“ sein muss Mit diesem Vorgang wird der Aktualwert (Present_Value) eines Objektes vom Prozess entkoppelt (System-Standardbeschreibung)

k Festlegung, welche Objekte bei Bedarf dynamisch erzeugt oder gelöscht werden können, z.B. für:

k,1 - Trendaufzeichnung k,2 - Ereignisaufzeichnung (kommt in der Norm) k,3 - Meldungsklassen 6 Festlegung der IOB für künftige Erweiterungen, je System- oder Produktkopplung Schritt 3 F Anforderungen an die Systemfunktionen der Bedien- und

Managementeinrichtungen (Softwarelizenzen)

1 Aus bisher aufgestellten GA-Funktionslisten gehen ein Teil der erforderlichen „Systemfunktionen" hervor, für weitere gilt das STLB-Bau 070 als „Checkliste“

2 Achten Sie hierbei auf die Merkmale der Interoperabilitätsbereiche, welche auf Ihr Projekt zutreffen – siehe den VDI/BIG-EU - BACnet-Leitfaden

Schritt 4 G Anforderungen an die Netzwerktechnik (LAN) für die Datenübertragung in der

jeweiligen funktionalen Ebene

1 Auswahl - siehe BACnet Leitfaden 2 Prüfung, ob ggf. vorhandene Netze verwendet werden sollen/können

(z.B. Liegenschafts- oder Büronetzwerk, Raumautomationsnetzwerk)

3 Festlegung, dass auf allen Netzwerken das BACnet-Protokoll lauffähig ist. Vorgabe in der Projekt- und Netzwerkbeschreibung

4 Festlegung, dass alle GA-Einrichtungen („Devices“) die für die geforderte Interoperabilität erforderliche BACnet-Funktionalität erfüllen. Vorgabe in der Standardbeschreibung („Vorbemerkung“) für die System-Hardware, (Vorsicht bei getrennter Vergabe des Netzwerks).

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 128

Nr. Aktivität Check Schritt 5 H Festlegung von speziellen, projektspezifischen Anforderungen bei Bedarf

zusätzliche BACnet-Funktionalitäten für:

1 Dienste 2 Engineering 3 Redundanzen 4 … Anhang G Web-Adressen zur GAEB- Schnittstelle: www.bvbs.de, www.nixkeitel.de, www.mwm.de, www.marktuebersicht.de, www.gaeb2000.de, www.gaeb-toolbox.de, www.gaeb-online.de, www.gaeb-konverter.de www.din-bauportal.de und natürlich auch www.gaeb.de Dipl.-Ing. Hans R. Kranz VDI, HAK Unternehmensberatung, Forst, kann zum Thema Anwendung des STLB-Bau für Gebäudeautomation Unterstützung geben, bitte Angebot anfordern: T 0172 2926021 [email protected]

HAK BACnet-Leitfaden2.8a-VDI-GA-BIG-EU-09-10-05.doc 129


Recommended