PDF

Transcrição

PDF

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
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
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
[email protected]
JCI Regelungstechnik GmbH
Karl Leber
[email protected]
ISC Computerautomation GmbH
Hans R. Kranz VDI
[email protected]
ehemals Siemens Building Technologies AG
HAK Ingenieurberatung, Forst/Baden
Christian Müller
[email protected]
Honeywell AG
Markus Ruf
[email protected]
ehemals Ebert-Ingenieure
Citect Software Vertriebsgesellschaft mbH
Panjörg Salzmann
[email protected]
ehemals Amann GmbH
Hans Symanczik
[email protected]
Kieback & Peter GmbH & Co. KG
Siegfried Weikmann
[email protected]
Planungsgruppe M+M AG
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
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 BACnetSysteme.
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
481
Gebäudeautomation
Automationssysteme
482
Schaltschränke
483
Management- und
Bedieneinrichtungen
484
Raumautomationssysteme
485
Übertragungsnetze
489
Gebäudeautomation,
sonstiges
Kosten der anlagenübergreifenden Automation
Automationsstationen mit Bedien-, und Beobachtungseinrichtungen,
GA-Funktionen, Anwendungssoftware/Lizenzen, Sensoren und
Aktoren, Schnittstellen zu Feldgeräten und anderen
Automationseinrichtungen
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
Übergeordnete Einrichtungen für GA und Gebäudemanagement mit
Bedienstationen, Programmiereinrichtungen,
Anwendungssoftware/Lizenzen, Servern, Schnittstellen zu
Automationseinrichtungen und externen Einrichtungen
Raumautomationsstationen mit Bedien- und Anzeigeeinrichtungen,
Schnittstellen zu Feldgeräten und anderen Automationseinrichtungen
Netze zur Datenübertragung, soweit nicht in anderen Kostengruppen
erfasst
Dipl.-Ing. Hans R. Kranz VDI, Forst / Baden
Im September 2006
HAK
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
1.2
1.3
1.4
1.5
Hinweise zu den Kommunikationsfunktionen.............................................................................. 16
1.6
2
Allgemeines ............................................................................................................................. 10
Das BACnet Modell der Gebäudeautomation.......................................................................... 11
Hinweise zur deutschen Übersetzung ..................................................................................... 12
Verwendete Begriffe und Definitionen nach DIN EN ISO 16484-2 ......................................... 15
Kommunikationspfade in GA-Systemen nach DIN EN ISO 16484-2 ...................................... 19
Spezifikation interoperabler BACnet-Systeme................................................................................ 20
2.1
2.2
3
Ziel von BACnet ....................................................................................................................... 20
Festlegen der Anforderungen an interoperable Systeme........................................................ 20
Interoperabilitätsbereiche – IOB ..................................................................................................... 21
3.1
3.2
3.3
3.4
3.5
3.6
4
Definition .................................................................................................................................. 21
DS - Gemeinsame Datennutzung (en: data sharing) .............................................................. 21
AE - Alarm- und Ereignisverarbeitung ..................................................................................... 23
SCHED - Zeitplan (en: scheduling).......................................................................................... 24
T - Trendaufzeichnung (en: trending) ...................................................................................... 25
DM - Device und Netzwerk-Management................................................................................ 26
Anwendung von BACnet-Objekten ................................................................................................. 28
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
5
Beschreibung der BACnet Objekttypen ................................................................................... 28
BACnet Objekttypen und GA-Funktionen der EN ISO 16484-3 bzw. VDI 3814-1:2004 ......... 29
Tabellarische Übersicht BACnet-Objekte – GA-Funktionen.................................................... 30
Adressierungs- (Namens-) Konventionen................................................................................ 33
Systemengineering und Diagnose über BACnet Dienste........................................................ 34
Benutzung der Objekt-Beschreibung....................................................................................... 35
Anmerkung zu Kommunikations-Objekttypen ......................................................................... 35
Erzeugen von BACnet Objekten im laufenden Betrieb............................................................ 38
Anwendung von BACnet Diensten.................................................................................................. 39
5.1
5.2
5.3
5.4
5.5
6.
Prioritätensteuerung für interoperable Aufträge/Befehle ......................................................... 39
Ereignis Management in BACnet Systemen............................................................................ 40
Festlegung der Benutzer-Zugriffskontrolle............................................................................... 42
Verarbeitung von Wertänderugen – COV................................................................................ 42
Zeitsynchronisierung................................................................................................................ 43
GA-Netzwerk Architektur ............................................................................................................. 44
6.0
6.1
6.2
6.3
HAK
GA-Netzwerke.......................................................................................................................... 44
Netzwerk Struktur .................................................................................................................... 45
Auswahl der LAN (Local Area Network) Option ..................................................................... 46
Strukturierte Vorgabe von MAC-Adressen .............................................................................. 51
6
6.4
6.5
6.6
6.7
6.8
6.9
7.
Netzwerknummerierung........................................................................................................... 53
Device-Objekt Adressierung .................................................................................................... 54
Verwendung von BACnet mit Internet-Protokollen .................................................................. 55
Routervernetzung von mehreren BACnet-Netzwerken ........................................................... 58
Datensatz-Segmentierung ....................................................................................................... 58
Gateway-Anschluss zu proprietären Systemen....................................................................... 58
Hinweise für die Planung und Ausführung von BACnet Systemen............................................. 61
7.0
7.1
7.2
7.3
7.4
8.
Allgemeines ............................................................................................................................. 61
Planung und Vergabe .............................................................................................................. 61
Montageplanung ...................................................................................................................... 62
Protokollanalysator und Inbetriebnahme ................................................................................. 63
Dokumentation und Schulung.................................................................................................. 64
Rechtliche Bewertung öffentlicher Ausschreibungen.................................................................. 66
8.1
8.2
8.3
8.4
8.5
8.6
8.7
9
Rechtliche Aspekte in Bezug auf die VOB............................................................................... 66
Besonderheiten in Bezug auf spezielle Produkte oder "Technologien" .................................. 66
Leistungen für Gebäudeautomation nach VOB....................................................................... 67
VOB/B § 8 und 9, Gründe für die Kündigung des Vertrages ................................................... 67
Anforderungen an ein Leistungsverzeichnises nach VOB/A § 9 ............................................. 67
Aufteilung in Fachlose und Änderung der zu erbringenden Leistung...................................... 68
Einzukalkulierende Nebenleistungen....................................................................................... 68
Rechtliche Aspekte der Systemintegration.................................................................................. 69
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
Einleitung ................................................................................................................................. 69
Verantwortung für Sicherheit ................................................................................................... 69
Verträge und Versicherungen.................................................................................................. 69
Die geschuldete Leistung (und Funktions- oder Meldungsversagen) ..................................... 70
Die vertragliche Haftung im Falle von Fehlfunktion, Störung, Personenschaden ................... 70
Funktion des "integrierten Gesamtsystems"............................................................................ 70
Versicherungsaspekte ............................................................................................................. 71
Die wesentlichen Anforderungen............................................................................................. 71
Gesetzliche Haftung, verschuldensunabhängig ...................................................................... 71
Pflichten des Systemintegrators oder Errichters.................................................................. 72
Gesetzliche Haftung, verschuldensabhängig....................................................................... 73
Normen (speziell fürs Gefahrenmanagement)..................................................................... 73
Grundlagen der Sicherheit ................................................................................................... 74
Hilfestellung.......................................................................................................................... 74
Anhang A
A.0
A.1
A.2
A.3
A.4
A.5
A.6
A.7
BIBBs Zusammenfassung als „Handliste“ ............................................................................... 75
Data Sharing BIBBs ................................................................................................................. 77
Alarm and Event Management BIBBs ..................................................................................... 79
Scheduling BIBBs .................................................................................................................... 81
Trending BIBBs........................................................................................................................ 82
Device Management BIBBs..................................................................................................... 83
Virtual Terminal BIBBs............................................................................................................. 88
Network Management BIBBs................................................................................................... 89
Anhang B
B.1
B.2
B.3
B.4
HAK
BACnet Interoperability Building Blocks (BIBBs).............................................................. 75
BACnet Device - Profile .................................................................................................... 90
BACnet Operator Workstation (B-OWS).................................................................................. 90
BACnet Building Controller (B-BC) .......................................................................................... 91
BACnet Advanced Application Controller (B-AAC).................................................................. 91
BACnet Application Specific Controller (B-ASC) ..................................................................... 92
7
B.5
B.6
B.7
B.8
BACnet Smart Actuator (B-SA)................................................................................................ 92
BACnet Smart Sensor (B-SS).................................................................................................. 93
BACnet Gateway (B-GW) ........................................................................................................ 93
IOB- Profile der Standard BACnet Devices ............................................................................. 94
Anhang C
C.1
C.3
C.4
C.4
Normung in Europa........................................................................................................... 95
Unterschiede Europa / USA..................................................................................................... 95
Einschränkungen bei den europäischen Vor- bzw. Experimentalnormen............................... 95
Die Struktur der GA-Normung in Europa, Stand 2004 ............................................................ 96
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
E.2
E.3
E.4
Leistungsbereich 070 - GAEB - XML Version ....................................................................... 109
Beispiele aus Texten des STLB-Bau 070 .............................................................................. 115
Freie Textbeispiele für Standardbeschreibungen.................................................................. 121
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
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:
www.BIG-EU.org
[email protected]
HAK
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
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 ionsprot okoll
Service M essages (APDUs)
BACS netw ork
F
F
A pplic.
Obj.
A pplic.
F
F
A pplic.
BACnetOWS
Bedienstation /-gerät
BACnetMS Management-/ Server Station
Obj.
BACnetASC
Controller
A pplic.
Obj.
Obj.
BACnetAS / BC
Automationsstation
BACnetAAC
Automationsgerät
Lokale Automations
Station
Obj.
BA Cnet SFD
Legende:
Applic.
APDUs
BACS network
BACnetBAS/BC
BACnetAAC
BACnetASC
BACnetOWS
BACnetMS
BACnetSFD
BACS
F
Obj.
Feldgeräte
Feldgeräte
Feldgeräte
Feldgeräte
GA Anwendungsprogramme (Applications)
Daten-Telegramme (Application protocol data units)
GA- Netzwerk (BACnet - Building automation and control network)
Automationsstation (BACnet building automation station / building controller)
Automationsgerät (BACnet Advanced application controller)
Anwendungsspezifische Geräte (BACnet application specific controller)
Bedienstation/-gerät (BACnet operator work station)
Management/Server Station (BACnet management station)
Vernetzbare Sensoren / Aktoren (BACnet smart field device)
GA-System (Building automation and control system)
Nachrichtenfilter (Filtering function)
GA- Kommunikations-Objekte (BACnet objects)
Bild 1-1 – ISO BACnet und seine Device-Typen im Modell der Gebäudeautomation (HAK)
HAK
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 BranchenNomenklatur 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 BACnetSysteme 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)
BACnetInteroperabilitä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 ZLTZeit wurde der Begriff "Auftrag" gewählt.
Mit einem "Gruppenauftrag" sollen Befehle von
unterschiedlichen Instanzen (Ausgabe-Objekten)
"gleichzeitig" ausgeführt werden.
Siehe auch "Relinquish Command - AuftragsZurü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
12
Originalsprache
(Sortierkriterium)
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 "BACnetDevices" implementiert werden (z. B. Gateway) und
dass ein "Device" nur virtuell (als Software)
vorhanden ist.
device and network
management - DM
Device- und NetzwerkManagement,
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 "HardwareObjekt"; 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
13
Originalsprache
(Sortierkriterium)
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 PICS
Conformance Statement Protokoll(PICS)
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-AufzeichnungsObjekt
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
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", "EMVGesetz"). 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 GAHersteller 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
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,
Zustandsund
zugehörige
Statusbeschreibungen,
Textund
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
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
Managementund
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 Managementund 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:
-
HAK
Device-Objekt; (engl.: device object; nach DIN EN ISO 16484-2: Hardwareobjekt); als SystemGrundparameter (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
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: EreignisLangzeitspeicherung (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 TrendAufzeichnungs-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
18
1.6
Kommunikationspfade in GA-Systemen nach DIN EN ISO 16484-2
Programmiereinheit
Datenschnittstelleneinheit
System für
besondere
Anwendungen
Bedienstation /
Bediengerät
System für
besondere
Anwendungen
Netzwerk
Kommunikationseinheit /
Controller /
ASR
Bediengerät
Anwendungsspezifische
Steuer- und Regeleinheit
(ASR)
Controller / Automationsstation /
ASR
Lokale VorrangBedieneinheiten
Raumbediengerät
Feld
System für
besondere
Anwendungen
Datenverarbeitungseinrichtung /
Serverstation
Programmiereinheit
Automation
Netzwerk
Netzwerk
Management
Bedienstation /
Bedieneinheit
Netzwerk
M
M
M
M
Verbindungen innerhalb der funktionalen Ebenen
Verbindungen zwischen den funktionalen Ebenen
Jalousien / Sonnenschutz
Licht / Dimmen
Bild 2: EN ISO 16484-2 Mögliche Verbindungen in GA-Systemen
HAK
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
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Festlegen der Anforderungen an interoperable Systeme
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).
Festlegung der benötigten GA-Funktionen für die Bedienung und Beobachtung der Anlagen.
Festlegung der benötigten GA-Funktionen für die Managementaufgaben.
Festlegung der IOBs (Interoperabilitätsbereiche) (Kapitel 3).
Festlegung der Funktionen, welche die jeweiligen Teil-Systeme unter Berücksichtigung der
Merkmale für die IOBs (Interoperabilitätsbereiche) erfüllen sollen.
Festlegung der vorgesehenen Netzwerktechnik (LAN oder WAN).
Festlegung der Netzwerktrassen mit Bestimmung der Entfernung zwischen den Einrichtungen gem.
Muster GAEB Beiblatt 070-10
Festlegung, dass auf den Netzwerken der TGA das BACnet-Protokoll lauffähig ist,
Festlegung dass die entsprechenden Einrichtungen die BACnet-Profile aufweisen, welche gem.
Anhang B dieses Dokuments gefordert sind.
Festlegung der zusätzlich erforderlichen BACnet Merkmale, die aus den Empfehlungen in diesem
Dokument hervorgehen.
Ermitteln der erforderlichen Massen für das Leistungsverzeichnis.
Aufstellen der Leistungsbeschreibung
Für öffentliche Bauvorhaben wird eine Ausschreibung mit Vergabeunterlagen nach VOB/A §10
verlangt, für private wird diese empfohlen.
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.de
www.BEUTH.de
www.GAEB.de
www.bundesaussschreibungsblatt.de
HAK
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 BACnetSystem 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
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 GAFunktionsliste, 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 GAFunktionen 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äteVordergrund,
…….
HAK
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).
-
3.3
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.
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 GANetzwerk; 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.
-
HAK
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.
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
Grenzwertüberwachung.
Kommunikations-
und
Bedienfunktionen
für
feste
oder
gleitende
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.
-
3.4
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).
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.
-
HAK
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.
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.
-
3.5
Festlegung der Zeitplaneinträge, die über das GA-Netzwerk von einem berechtigten Bediener im Fremdsystem
veränderbar sind.
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 TrendDiagramm-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 ObjektTypen), 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.
-
HAK
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 TrendDiagramm (Name) verwiesen werden.
o ANMERKUNG: In der Regel richten sich die Bediener selbst die benötigten Trend-Diagramme ein.
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 GANetzwerk 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.
-
3.6
Festlegung der Änderbarkeit von Trendaufzeichnungs-Parametern durch berechtigte Bediener. Zu den
Parametern gehören das Zeitraster und die Dauer der Aufzeichnung.
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 BACnetObjekten 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.
-
HAK
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.
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 GANetzwerk 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.
-
HAK
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.
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 DatenArten 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
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 BACnetObjekttypen 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 ObjekttypBezeichnungen aus dem original BACnet-Standard. Durch erhebliche Unterschiede der
HAK
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 3814Standard.
4.3
Tabellarische Übersicht BACnet-Objekte – GA-Funktionen
Die folgende Übersichts-Tabelle 4-01 zeigt auf, wie die BACnet-Objekttypen mit den Funktionen der GAFL 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
kommunikative Funktion 2.5 bzw. 7.1.
Messen, z. B. Temperaturmessung,
3.
Analog Output AO
Analogausgabe
Stellen, 1.2
Stellen, z. B. Stellbefehl für Regelventil,
4.
Analog Value AV
Analogwert
Virtueller analoger DP
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
Digital dargestellter Wert aus Statistikfunktion
als Mittelwert mit Minimum, Maximum und
Varianz,
6.
Binary Input BI
Binäreingabe
Melden, 1.3
Melden (z. B. Betriebszustands- Störungsoder Alarmmeldung),
7.
Binary Output BO
Binärausgabe
Schalten, Stellen, 1.1
Schalten (z. B. Schaltbefehl Ein/Aus,
Stellbefehl Auf/Zu),
HAK
30
EN – ISO 16484 / VDI 3814-1
BACnet-Objekttyp
Originalsprache;
Deutsche
Übersetzung
Datenpunkttyp
GA-Funktionsliste,
(Abschnitt.Spalte)
Bedeutung
(Abschnitt.Spalte)
8.
Binary Value BV
Binärwert
Virtueller binärer DP
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 ManagementKommunikationsfunktion 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 GAFunktionen enthalten.
13. Event Log ELOG
EreignisAufzeichnung
Ggf. virtueller DP
Bei Fremdkopplung als virtueller DP mit
Ü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
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
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 ManagementKommunikationsfunktion 7.2
Informationen über die Properties für
Gefahrenmelde-Anwendungen im Netzwerk.
Abgeleitete Aktionen sind entsprechende GAFunktionen.
18. Life Safety Zone
LSZ
Sicherheitsbereich
Virtueller DP
Management-Kommunikationsfunktion 7.2
Zusammenfassung von GefahrenmelderObjekten, 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
Properties (Attribute und Parameter) von
Regelfunktionen, enthalten in den GAFunktionen z. B. 5.1-5.8, 7.3, 7.4, 8.2.
HAK
31
EN – ISO 16484 / VDI 3814-1
BACnet-Objekttyp
Originalsprache;
Deutsche
Übersetzung
Datenpunkttyp
GA-Funktionsliste,
(Abschnitt.Spalte)
Bedeutung
(Abschnitt.Spalte)
20. Multi-state Input MI
Mehrstufige
Eingabe
Melden, 1.3
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
kommunikative Funktion je Stufe, 2.1 bzw.
7.1.
Logische Ausgabezustände als Zahl kodiert, z.
B. Schaltbefehl: Aus, Stufe 1, Stufe 2, ....
22. Multi-state Value
MV
Mehrstufiger Wert
Virtueller mehrstufiger DP
kommunikative Funktion je Stufe, 2.1, 2.3,
bzw. 7.1.
Logische Zustände als Zahl kodiert, z. B.
Zustandsdefinition 1,2,3, …
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
Zugriff auf ein Programm in einem BACnetDevice, 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.
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
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
Abonnement auf einen Wert für zeitweise
ereignisorientierte Übertragung (COVReporting) für Trendaufzeichnung.
I. d. R. Keine Funktion nach 7.3/7.4.
28. Trend Log Multiple
TLOGM
Mehrfachtrendaufzeichnung
Ggf. virtueller DP
Abonnement auf mehrere Werte für zeitweise
ereignisorientierte Übertragung (COVReporting) oder "Lesen" von Werten für z. B.
netzwerkübergreifende Trendaufzeichnung.
I. d. R. Keine Funktion nach 7.3/7.4.
HAK
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 ObjektProperties von Datenpunkten. Dieses muss von allen beteiligten Herstellern genutzt werden.
-
HAK
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.
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):
Ortskennung
000
AAA
00
Anlagenkennung
A000
AAA
00
00
AA
00
AA
00
AA
00
Gewerk
nach
DIN 276
Objekt
Gebäude /
Bauteil
000
GA-Kennung
Anlage und
Anlagennr.
Geschoß
Raum
Datenpunktart
und Nummer
Zonennummer
Anlagenteil
und Anlagenteilnummer
Einzelgerät
und Einzelgerätnummer
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.
-
HAK
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.
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-BeschreibungsProperty 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
HAK
Binäre Ausgabe
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 GAFunktionsliste 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 LVPosition 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 ObjektProperties
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 GAFunktionsliste 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
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 GAFunktionsliste 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.
-
HAK
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.
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 LVPosition 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.
-
HAK
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.
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ätenebene
1
2
3
4
5
6
7
8
Anwendung
Manual-Life Safety
(Sicherheit – Hand)
Automatic-Life Safety
(Sicherheit - Automatik)
Frei Verfügbar
Frei Verfügbar
Critical Equipment Control
(Kritische Anwendung)
Minimum On/Off (Ein/Aus)
Frei Verfügbar
Manual Operator
(Hand)
Prioritätenebene
9
Anwendung
Frei Verfügbar
10
Frei Verfügbar
11
12
13
Frei Verfügbar
Frei Verfügbar
Frei Verfügbar
14
15
16
Frei Verfügbar
Frei Verfügbar
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
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 TONORMAL. 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
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 EreignisAnweisungstexte 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
41
-
-
5.3
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.
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
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.
-
5.5
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.
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.
-
HAK
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.
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
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
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 Voraber 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
46
Die wesentlichen Merkmale des Ethernet nach ISO/IEC 8802-3 sind in der Tabelle 6-1 zusammengefasst:
Geschwindigkeit
kB/s
10.000 100.000
NPDU1
Größe
(Bytes)
1497
Pro
Kontra
- Internationale Norm
- hohe Kosten, wenn nicht als
- Meist bereits im Gebäude vorhanden
Infrastruktur vorhanden
- Vielzahl bewährter Medien
- Entfernungsbegrenzungen zu
(TP, Koax, Fiberoptik, Funk)
beachten
- Sehr schnell
- Nicht deterministisch (was
- Einfacher, günstiger PC-Anschluss
durch hohe Geschwindigkeit
- Kein spezielles Entwicklungstool
und Netzwerksegmentierung
- Riesige Produktauswahl für alle
nicht stört)
Komponenten
- Fallende Kosten
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 EMVtechnisch 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
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.
Geschwindigkeit
kB/s
156 7.500
NPDU1
Größe
(Bytes)
501
Pro
Amerikanische Norm
Deterministisch
Anpassbare Geschwindigkeit
Medienauswahl
(TP, Koax, Fiberoptik)
- Schnell
- Kein spezielles Entwicklungstool
- Gutes Kosten-Nutzen- Verhältnis
-
Kontra
- 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
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.
Geschwindigkeit
kB/s
9.6 78.400
NPDU1
Größe
(Bytes)
501
Pro
-
Amerikanische Norm
Low-Cost-Lösung
Auf Einchip- Mikroprozessor möglich
Deterministisch
keine speziellen
Entwicklungswerkzeuge erforderlich
Kontra
- 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
49
Genau wie bei Ethernet und ARCNET ist das LonTalk Protokoll in einem Chip, dem sogenannten NeuronChip 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.
Geschwindigkeit
kB/s
4,8 1.250
NPDU1
Größe
(Bytes)
228
Pro
- Medienvielzahl
(TP, Koax, Funk, Infrarot,
Fiberoptik)
- Anpassbare Geschwindigkeit
-
Kontra
- 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
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.
Geschwindigkeit
kB/s
9.6 - 56
NPDU1
Größe
(Bytes)
(501)
Pro
- Einzige Auswahl für
Wählverbindungen
- Zugeschnitten auf Punkt-zuPunkt-Anwendungen
- Angepasst an moderne ModemStandards (V.32bis, V.42)
Kontra
- 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
51
wird, ist eine spezielle Adressenkonfiguration nicht notwendig. Für andere BACnet-LANs gilt: die MACAdresse 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 MACAdresse 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.
-
HAK
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.
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 SlaveDevices 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 DDCRegelgerä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 MACAdresse 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 SlaveAdressenplä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 NodeKonfigurationen 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
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:
BBB
FF
FF
BBBFF
= ist eine Nummer zwischen 1 und 655, zugeordnet zu jedem Gebäude
= 00 für das Gebäude-Backbone-Netzwerk
= 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 IPPort 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 BACnetNetzwerknummern 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 ObjektIdentifizierungsmerkmal des Device-Objekts haben muss. Diese Adressierung ist die Basis für BACnetDienste, 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 HardwareObjekt-Identifizierungsmerkmal-Daten so verwaltet werden, dass keine Adresse (Nummer) dupliziert wird.
HAK
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-ObjektIdentifikationsmerkmale (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:
Wobei:
XX
FF
FF
BBB
XXFFBBB
= ist eine Nummer im Bereich zwischen 00 - 40
= 00 für das Gebäude-Backbone-Netzwerk
= 1-35 für die Stockwerksbezeichnung oder für
separate Projekte innerhalb des Gebäudes
= 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 HardwareObjekt-Identifikationsmerkmal getrennt werden kann. Dadurch sind viele gültige ObjektIdentifikationsmerkmal-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-NetzwerkNummer, 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
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
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 (BACnetBroadcast-Management-Device) verfügbar sein, ebenso müssen entsprechende Vorkehrungen für die
Anwendung von IP-Multicasting getroffen werden.
HAK
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 BACnetEthernet-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-SchichtFehlermeldungen zu bestimmten Bedienstationen gesendet werden, unter Verwendung der BACnetConfirmedTextMessage-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
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 BACnetLAN 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 BACnetEinrichtungen 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 LVPosition 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
59
Automationseinrichtung erstellt werden, nicht übertragen. Es ist wichtig zu verstehen, welche TrendAufzeichnungs-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 TrendAufzeichnung 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.
-
HAK
Im LV werden die Art und Weise Ereignis– und Alarmbehandlung und die dafür vorgesehenen
Datenpunkte festgelegt.
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:
-
HAK
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
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.
2.
3.
4.
5.
HAK
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;
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.
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.
Spezielle Funktionalitäten.
Hier werden alle speziellen Ausnahmen beschrieben, welche eine Einrichtung gegenüber dem
BACnet-Protokoll für spezifische Funktionen hat.
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.
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 NichtStandard 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-TestOberflächen-Software verfügbar. Die Analysatorsoftware kann je nach Projekterfordernis auf einen
Notebook oder auf einem PC installiert werden.
HAK
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
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
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
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 GAFunktionen 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
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 LVText 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
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
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
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
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 Produktbeobachtungsund 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 EURichtlinien 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
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
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
74
Anhang A BACnet Interoperability Building Blocks (BIBBs)
Die BACnet Interoperabilitätsbausteine (BIBBs) sind eine Sammlung von einem oder mehreren BACnetDiensten. 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
DSDS-RP-A/B
DS-RPM-A/B
DS-RPC-A/B
DS-WP-A/B
DS-WPM-A/B
DS-COV-A/B
DS-COVP-A/B
DS-COVU-A/B
AEAE-N-A
AE-N-I-B
AE-N-E-B
AE-ACK-A/B
AE-ASUM-A/B
AE-ESUM-A/B
AE-INFO-A/B
AE-LS-A/B
SCHEDSCHED-A
SCHED-I-B
SCHED-E-B
THAK
BIBB Bezeichnung
Gemeinsame Datennutzung (Data Sharing BIBBs)
BIBB – Data Sharing-ReadProperty-A/B, A liest Property von B.
BIBB – Data Sharing-ReadPropertyMultiple-A/B, A liest mehrere Werte gleichzeitig von B.
BIBB – Data Sharing-ReadPropertyConditional-A/B, A liest gem. Bedingung Property von
B.
BIBB – Data Sharing-WriteProperty-A/B, A schreibt auf Property in B.
BIBB – Data Sharing-WritePropertyMultiple-A/B, A schreibt mehrere Werte gleichzeitig in
B.
BIBB – Data Sharing-COV-A/B, A abonniert Informationen über Wertänderungen von B.
BIBB – Data Sharing-COVP-A/B, A abonniert Informationen über Wertänderungen eines
speziellen Property von B.
BIBB – Data Sharing-COV-Unsolicited-A/B, A verarbeitet unaufgefordert gesandte COVWerte von B.
Alarm und Ereignis-Management (Alarm and Event Management BIBBs)
BIBB – Alarm and Event-Notification-A, A verarbeitet Meldungen von B.
BIBB – Alarm and Event-Notification Internal-B, B erzeugt Meldungen
(unterstützt objektinternes (intrinsic) und regelbasiertes (algorithmic) Melden (reporting).
BIBB – Alarm and Event-Notification External-B, B erzeugt Meldungen (regelbasiert mit
Ereigniskategorie-Objekt).
BIBB – Alarm and Event-ACK-A/B, A quittiert Meldungen von 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).
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).
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)
BIBB – Alarm and Event-LifeSafety-A/B, A fordert Alarmruhe oder Alarmrücksetzung von
Gefahrenmeldeeinrichtung B.
Zeitplan (Scheduling BIBBs)
BIBB – Scheduling-A, A verändert Zeitplaneinstellungen in B.
BIBB – Scheduling-Internal-B, B führt bis zu 6 eingetragene Schaltungen pro Tag bei
eigenen Datenpunkten aus.
BIBB – Scheduling-External-B, B führt bis zu 6 eingetragene Schaltungen pro Tag bei
Datenpunkten im GA-Netzwerk aus.
Trendaufzeichnung (Trending BIBBs)
75
BIBB Kürzel
T-VMT-A
T-VMT-I-B
T-VMT-E-B
T-ATR-A/B
T-VMMV-A
T-VMMV-I-B
T-VMMV-E-B
T-AMVR-A/B
DM/NMDM-DDB-A/B
DM-DOB-A/B
DM-DCC-A/B
DM-PT-A/B
DM-TM-A/B
DM-TS-A/B
DM-UTC-A/B
DM-RD-A/B
DM-BR-A/B
DM-R-A/B
DM-LM-A/B
DM-OCD-A/B
DM-VT-A/B
NM-CE-A/B
NM-RC-A/B
HAK
BIBB Bezeichnung
BIBB – Trending-Viewing and Modifying Trends-A, A fordert Trendwerte von B und zeigt
diese an.
BIBB – Trending-Viewing and Modifying Trends Internal-B, B sammelt Trendwerte eigener
Datenpunkte für A.
BIBB – Trending-Viewing and Modifying Trends External-B, B sammelt Trendwerte von
Datenpunkten im GA-Netzwerk für A.
BIBB – Trending-Automated Trend Retrieval-A/B, A reagiert auf die Meldung von B, dass
die gesammelten Trendwerte zur Abholung bereit stehen.
BIBB – Trending-Viewing and Modifying Multiple Values-A, A zeigt die Daten der
Trendwerte von B und verändert die Trendparameter in B.
BIBB – Trending-Viewing and Modifying Multiple Values-Internal –B, B sammelt
Mehrfach-Trendwerte im eigenen Device.
BIBB – Trending-Viewing and Modifying Multiple Values-External –B, B sammelt
Mehrfach-Trendwerte auch von anderen Devices.
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
Device- und Netzwerkmanagement, (Device and Network Management BIBBs)
BIBB – Device Management-Dynamic Device Binding-A/B, A sucht Informationen über
andere Devices im GA-Netzwerk und interpretiert entsprechende Ankündigungen (Who-Is / IAm)
BIBB – Device Management-Dynamic Object Binding-A/B, A sucht im GA-Netzwerk
Adressinformationen über BACnet-Objekte (Who-Has, I-Have)
BIBB – Device Management-DeviceCommunicationControl-A/B, A übt die Kontrolle über
das Kommunikationsverhalten von B aus.
BIBB – Device Management-Private Transfer-A/B, A löst die Übertragung proprietärer
Daten von B mittels eines BACnet-Dienstes aus.
BIBB – Device Management-Text Message-A/B, A löst die Übertragung von freiem Text für
B aus.
BIBB – Device Management-TimeSynchronization-A/B, A stellt B eine
Zeitsynchronisierung mit der lokalen Uhrzeit zur Verfügung.
BIBB – Device Management-UTCTimeSynchronization-A/B, A stellt B eine
Zeitsynchronisierung mit der UTC-Weltzeit (GMT) zur Verfügung.
BIBB – Device Management-ReinitializeDevice-A/B, A veranlasst B zu einem Warm- oder
Kaltstart der Software.
BIBB – Device Management-Backup and Restore A/B, A liest die Konfigurationsdaten von
B und schreibt diese bei Bedarf zurück.
BIBB – Device Management-Restart-A/B, A verarbeitet Wiederanlauf-Meldungen von B
mit Interpretation der Gründe.
BIBB – Device Management-List Manipulation-A/B, A fügt Listenelemente in Properties von
B hinzu oder entfernt diese.
BIBB – Device Management-Object Creation and Deletion-A/B, A erstellt oder entfernt
BACnet-Objekttypen in B.
BIBB – Device Management-Virtual Terminal-A/B, A startet eine Virtual Terminal Sitzung
mit B
(direkte Kommunikation mit dem B Prozessor).
BIBB – Network Management-Connection Establishment-A/B, A veranlasst Modems
(Halbrouter) zum Auf- und Abbau von Verbindungen, B führt diese Kommandos aus.
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.
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
ReadProperty
A.1.2
Initiate
x
Execute
BIBB – Data Sharing-ReadProperty-B (DS-RP-B)
Das Device B ist der Anbieter von Daten für Device A
BACnet Service
ReadProperty
A.1.3
Initiate
Execute
x
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
ReadPropertyMultiple
A.1.4
Initiate
x
Execute
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
ReadPropertyMultiple
A.1.5
Initiate
Execute
x
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
ReadPropertyConditional
A.1.6
Initiate
x
Execute
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
ReadPropertyConditional
HAK
Initiate
Execute
x
77
A.1.7
BIBB – Data Sharing-WriteProperty-A (DS-WP-A)
Das Device A setzt (verstellt) einen Wert in Device B
BACnet Service
WriteProperty
A.1.8
Initiate
x
Execute
BIBB – Data Sharing-WriteProperty-B (DS-WP-B)
Das Device B erlaubt die Verstellung eines Wertes durch Device A.
BACnet Service
WriteProperty
A.1.9
Initiate
Execute
X
BIBB – Data Sharing-WritePropertyMultiple-A (DS-WPM-A)
Das Device A setzt (verstellt) gleichzeitig mehrere Werte in Device B
BACnet Service
WritePropertyMultiple
Initiate
x
Execute
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
WritePropertyMultiple
Initiate
Execute
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
SubscribeCOV
ConfirmedCOVNotification
UnconfirmedCOVNotification
Initiate
X
Execute
X
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
78
BACnet Service
SubscribeCOV
ConfirmedCOVNotification
Initiate
Execute
X
X
X
DS-COV-B konforme Devices müssen mindestens 5 gleichzeitige Abonnements unterstützten.
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
Execute
x
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
X
Execute
DS-COVP-B konforme Devices müssen mindestens 5 gleichzeitige Abonnements unterstützten,
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
Execute
x
A.1.16 BIBB – Data Sharing-COV-Unsolicited-B (DS-COVU-B)
Das Device B generiert spontane (nicht angeforderte) COV Mitteilungen
BACnet Service
A.2
Initiate
X
Execute
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
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
ConfirmedEventNotification
UnconfirmedEventNotification
A.2.2
Initiate
Execute
x
x
BIBB – Alarm and Event-Notification-B (AE-N-B)
Device B generiert Mitteilungen über Alarme oder andere Ereignisse
BACnet Service
UnconfirmedEventNotification
Initiate
x
x
Execute
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
AcknowledgeAlarm
A.2.4
Initiate
x
Execute
BIBB – Alarm and Event-ACK-B (AE-ACK-B)
Devices B bearbeitet Bestätigungen von zuvor übertragenen Alarm-/Ereignismitteilungen
BACnet Service
AcknowledgeAlarm
Initiate
Execute
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
GetAlarmSummary
HAK
Initiate
x
Execute
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
GetAlarmSummary
A.2.7
Initiate
Execute
x
BIBB – Event-Summary-A (AE-ESUM-A)
Device A fordert Abonnement-Eintragungen für Ereignisnachrichten von Device B an
BACnet Service
GetEnrollmentSummary
A.2.8
Initiate
x
Execute
BIBB – Event-Summary-B (AE-ESUM-B)
Device B stellt Abonnement-Eintragungen für Ereignisnachrichten Device A zur Verfügung
BACnet Service
GetEnrollmentSummary
A.3
Initiate
Execute
x
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
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
ReadRange
A.4.2
Initiate
x
Execute
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
ReadRange
Initiate
Execute
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
ReadRange
Initiate
Execute
x
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
ReadRange
Initiate
x
Execute
x
T-ATR-B konforme Devices müssen das Trendaufzeichnungs-Objekt unterstützen.
HAK
82
A.5
Device Management BIBBs
Diese BIBBs beschreiben die BACnet Merkmale für die
Devicemanagement-Funktionen wie sie in 3.6 beschrieben sind.
interoperable
Unterstützung
der
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
Who-Is
I-Am
A.5.2
Initiate
x
Execute
x.
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
Who-Is
I-Am
A.5.3
Initiate
Execute
x
x
BIBB - Device Management - Dynamic Object Binding - A (DM-DOB-A)
Das Device A sucht Adressinformationen von BACnet Objekten.
BACnet Service
Who-Has
I-Have
Initiate
x
Execute
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
Who-Has
I-Have
Initiate
Execute
x
x
A.5.5 BIBB - Device Management - DeviceCommunicationControl - A (DM-DCC-A)
Das Device A übt die Kommunikationssteuerung über Device B aus.
BACnet Service
DeviceCommunicationControl
HAK
Initiate
x
Execute
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
DeviceCommunicationControl
Initiate
Execute
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
ConfirmedPrivateTransfer
UnconfirmedPrivateTransfer
Initiate
x
x
Execute
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
ConfirmedPrivateTransfer
UnconfirmedPrivateTransfer
Initiate
Execute
x
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
ConfirmedTextMessage
UnconfirmedTextMessage
Initiate
x
x
Execute
A.5.10 BIBB - Device Management - Text Message - B (DM-TM-B)
Das B-Device verarbeitet Text-Meldungen.
BACnet Service
ConfirmedTextMessage
UnconfirmedTextMessage
HAK
Initiate
Execute
x
x
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
TimeSynchronization
Initiate
x
Execute
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
TimeSynchronization
Initiate
Execute
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
UTCTimeSynchronization
Initiate
X
Execute
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
UTCTimeSynchronization
Initiate
Execute
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
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
ReinitializeDevice
Initiate
x
Execute
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
ReinitializeDevice
Initiate
Execute
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
AtomicReadFile
AtomicWriteFile
Create Object
ReinitializeDevice
Initiate
x
x
x
x
Execute
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
AtomicReadFile
AtomicWriteFile
ReinitializeDevice
Initiate
Execute
x
x
x
In DM-BR-B konformen Devices müssen nach einem Download das Read_Only Property für DateiObjekte, 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
86
Für das Zurückschreiben
DIN EN ISO 16484-5
der
Konfigurationsdatei
(Download)
siehe
Kapitel
19.1.3.3
A.5.18a BIBB - Device Management – Restart - A (DM-R-A)
Das A-Device bearbeitet Mitteilungen über einen Neustart.
BACnet Service
Initiate
Execute
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
X
Execute
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
AddListElement
RemoveListElement
Initiate
x
x
Execute
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
AddListElement
RemoveListElement
Initiate
Execute
x
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
CreateObject
DeleteObject
HAK
Initiate
x
x
Execute
87
in
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
CreateObject
DeleteObject
A.6
Execute
x
x
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
VT-Open
VT-Close
VT-Data
A.6.2
Initiate
X
x
Execute
X
x
X
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
VT-Open
VT-Close
VT-Data
HAK
Initiate
X
X
x
Execute
x
X
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
Establish-Connection-To-Network
Disconnect-Connection-To-Network
A.7.2
Initiate
x
x
Execute
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.
Establish-Connection-To-Network
Disconnect-Connection-To-Network
A.7.3
Initiate
Execute
x
x
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.
Who-Is-Router-To-Network
I-Am-Router-To-Network
I-Could-Be-Router-To-Network
Initialize-Routing-Table
Initialize-Routing-Table-Ack
HAK
Initiate
x
Execute
x
x
x
x
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
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
- 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,
- 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
bereitzustellen,
zuzulassen
HAK
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
- Fähigkeit, Anfragen über den Device-status zu beantworten,
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
bereitzustellen,
zuzulassen
Zeitprogramme
Trend-Aufzeichnung
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,
zuzulassen
HAK
92
Zeitprogramme
Trend-Aufzeichnung
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,
Zeitprogramme
Trend-Aufzeichnung
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.
- 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
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,
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.
IOB
Device-type
B-ASC
B-OWS
B-BC
B-AAC
B-SA
B-SS
B-GW
DS-RP-A,B
DS-RPM-A
DS-WP-A
DS-WPM-A
DS-RP-A,B
DS-RPM-A,B
DS-WP-A,B
DS-WPM-B
DS-COVU-A,B
DS-RP-B
DS-RPM-B
DS-WP-B
DS-WPM-B
DS-RP-B
DS-WP-B
DS-RP-B
DS-WP-B
DS-RP-B
DS-RP-B
DS-RPM-B
DS-WP-B
DS-WPM-B
B-OWS
AE-N-A
B-BC
AE-N-B
B-AAC
AE-N-B
B-ASC
B-SA
B-SS
B-GW
AE-N-B
AE-ACK-A
AE-ASUM-A
AE-ESUM-A
AE-ACK-B
A-ASUM-B
AE-ESUM-B
AE-ACK-B
AE-ASUM-B
B-OWS
SCHED-A
B-BC
SCHED-B
B-AAC
SCHED-B
B-ASC
B-SA
B-SS
B-GW
B-OWS
T-VMT-A
T-ATR-A
B-BC
T-VMT-B
T-ATR-B
B-AAC
B-ASC
B-SA
B-SS
Trending
B-GW
T-VMT-B
T-ATR-B
B-OWS
DM-DDB-A,B
DM-DOB-A,B
DM-DCC-A
DM-TS-A
B-BC
DM-DDB-A,B
DM-DOB-A,B
DM-DCC-B
DM-TS-B
oder
DM-UTC-B
B-AAC
DM-DDB-B
DM-DOB-B
DM-DCC-B
DM-TS-B
oder
DM-UTC-B
B-ASC
DM-DDB-B
DM-DOB-B
DM-DCC-B
B-SA
B-SS
Device &
Network
Mgmt
B-GW
DM-DDB-B
DM-DOB-B
DM-DCC-B
DM-TS-B
oder
DM-UTC-B
DM-RD-B
DM-BR-B
NM-CE-A
DM-RD-B
Data Sharing
Alarm &
Event Mgmt
Scheduling
DM-UTC-A
DM-RD-A
DM-BR-A
NM-CE-A
HAK
AE-ACK-B
A-ASUM-B
AE-ESUM-B
DM-RD-B
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
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.
Struktur
Struktur von
von CEN/TC247
CEN/TC247 im
im Sept.
Sept. 2006
2006
TC247
TC247
Building
Building
Automation,
Automation,
Controls,
Controls,and
and
Building
Building
Management
Management
C: Convenor
CC: Co-Convenor
PL: Project leader
WG
WG11
Controls
Controls
for
for
Heating
Heating
Systems
Systems
Secretary
SecretaryTC247
TC247
M. Schumacher
CH
President U. Wirth
Siemens, CH
WG
WG33
WG2
WG2
Building
Building
Automation
Automation
and
andControl
Control
Systems
Systems
Individual
Individual
Zone/Room
Zone/Room
Control
Control
WG
WG44
Open
OpenData
Data
Transmission
Transmission
C: D. Dietrich
TU Wien,
CC: P. Fischer
FH Dortmund
C: K. Churches
T.A.C. UK
PL: H.Kranz
WG
WG55
WG
WG66
Building
Building
Management
Management
Integrated
Integrated
Systems
Systemsand
and
Services
Services
Integrated
Integrated
Room
Room
Automation
Automation
C: D. Napar
Siemens, FR
CC: R. Cyssau
COSTIC, FR
PL: H.Kranz
Report Mutual Observer ISO/TC 205 WG 3 - CEN/TC 247, Hans R. Kranz, Paris FR, Oct.
Oct. 2006, Pg:
Pg: 18
Trade associations
Standardization organisations
Government
WTO Members
EUBAC
EUBAC
European
European Building
Building
Automation
Automation and
and Controls
Controls
Association
Association
CEN/TC
CEN/TC 247
247
Build.
Build. Automation,
Automation,
Controls
Controls and
and Building
Building Mgt.
Mgt.
European
European
ISO/TC205
ISO/TC205
Building
Building Environment
Environment
Design
Design
International
International
Abb. C 4-1: Stuktur des CEN Technischen Komitees (TC247) für die Gebäudeautomation
CEN/TC
CEN/TC 89,
89, 156,
156, 169,
169, 228
228
CLC/TC205
CLC/TC205
EPD
ACR
ACR France
France
AICAR
AICAR Italy
Italy
BCG
BCG UK
UK
VDMA
VDMA Germay
Germay
SSPC135
VDI 3814
National
National shadow
shadow groups
groups organized
organized
by
CEN
Members
active
by CEN Members active in
in CEN/TC247
CEN/TC247
e.g.
e.g. AFNOR,
AFNOR, BSI,
BSI, DIN,
DIN, DS,
DS, IBN,
IBN, IRL,
IRL,
NSF,
NSF, ON,
ON, SFS,
SFS, SIS,
SIS, SNV,
SNV, UNI
UNI
National
National
JWG
JWG 247-205
247-205
Abb. C 4-2: Verbindungen der Komitees für die Gebäudeautomation
HAK
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, STLBBauZ) 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
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 10Prozentgrenze, 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
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
99
C.5
HAK
Einführungsverordnung des STLB-Bau
100
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.
HAK
101
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
102
9) Falls erforderlich sind bei gemeinsamen (shared) Datenpunkten die Funktionen
im Client mit "A" und die im Server mit "B" zu kennzeichnen (siehe BIBBs)
9 10 11 12 13
3
4
1
2
Nachricht an externe Stelle
Dynamische Einblendung
2
7
8
Ereignis-Anweisungstext
1
Grafik / Anlagenbild
7
Ereignis-Langzeitspeicherung
6
6
5
Historisierung in Datenbank
5
Komplexer Objekttyp 8) 9)
4
Tarifabhängiges Schalten
3
Ein-/Ausgabe Objekttyp 9)
2
Netzwiederkehrprogramm
1
5
Nachtkühlbetrieb
8
Zyklisches Schalten
7
Zeitabhängiges Schalten
6
Gleitendes Ein- / Ausschalten
4
Ereignisabhängiges Schalten
3
Arithmetische Berechnung 7)
2
Parameterumschaltung
1
BedienManagementfunktionen
funktionen
Rechnen / Optimieren
h,x geführte Strategie 7)
5
Stellausgabe Pulsweitenmodulation
3
Begrenzung Sollwert / Stellgösse
4
4
4
Stellausgabe 2-Punkt 6)
Sollwertführung / -kennlinie
Stellausgabe stetig
2
PI / PID-Regelung
1
P-Regelung
6
Sicherheits-/ Frostschutzsteuerung
5
3
Umschaltung 5)
3
Folgesteuerung 5)
2
Motorsteuerung
1
Anlagensteuerung
3
Befehlsausführkontrolle
5
2
Verarbeitungsfunktionen
Regeln
Steuern
Meldungsbearbeitung 4)
4
Grenzwert gleitend
2
Betriebsstunden-Erfassung
1
Analoger Eingabewert, Messen
5
Überwachen
Grenzwert fest
3
Zählwerteingabe
Analoger Ausgabewert, Stellen/Sollwert
4
1
Binärer Eingabewert, Zustand
Binärer Ausgabewert, Schalten
2
Binäre Eingabe Zählen
1
Analoge Eingabe Messen 2)
Abschnitt
Spalte
Analoge Ausgabe Stellen
Datenpunkt
Z. B. DP-Name mit Nr.
Binäre Eingabe Melden
Zeile Nr.
Anlage
Binäre Ausgabe Schalten / Stellen 1)
Ein- / Ausgabefunktionen
Physikalisch Gemeinsam 3)9)
Ereigniszählung
Gewerk:
b) Verzögern und c) Unterdrücken von Meldungen
5) Pro Ausgangs-Benutzeradresse
Höchstlastbegrenzung
Pulsweitenmod.=1 BA
Netzersatzbetrieb
2) Aktiv oder passiv
Energierückgewinnung 7)
GA-Funktionsliste
6) Stellausgabe: Z.B. 3-Punkt = 2 x 2-Punkt
7) Pro Eingangs-Benutzeradresse
8) Z.B. Gerätestatus, Zeitschalttab., Sicherheitspkt., Regler, Datei (EN ISO 16484-5)
3) Nur gemeinsame, kommunikative Datenpunkte
von Fremdsystemen für interoperable Funktionen
4) Pro Eingangs-Benutzeradresse zum a) Zusammenfassen,
Raumtemperaturbegrenzung
Anhang A (normativ)
1) Dauerbefehl: Z.B. 0,I,II=2 BA
Impulsbefehl: Z.B. 0,I,II=3 BA
Stellbefehl: Z.B. Zu-0-Auf=2 BA
DIN EN ISO 16484-3
Bemerkungen
ANMERKUNG
Definition 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
8
9
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
Rev. 1
Rev. 2
Rev. 3
Name
Geprüft
Planersteller:
Projekt:
Informationsschwerpunkt:
Datei:
Zeichnungs-Nr.:
Steuerungsbeschr. Nr.:
Blatt Nr.1
von:
[Tabelle_ISO-GA-FL-Vorlage-1_050513.xls]
© 1996-2005 ISO/TC205_CEN/TC247_VDI-TGA_GAEB070
Beiblatt D 1 - Beispiel GA-Funktionsliste
HAK
103
9 10 11 12 13
1
2
Ereignis-Anweisungstext
4
7
8
Nachricht an externe Stelle
3
Dynamische Einblendung
2
Historisierung in Datenbank
7
Grafik / Anlagenbild
Komplexe Objekttyp 8) 9)
1
6
5
Ereignis-Langzeitspeicherung
6
Höchstlastbegrenzung
5
Tarifabhängiges Schalten
4
Netzersatzbetrieb
3
Ein-/Ausgabe Objekttyp 9)
BedienManagementfunktionen funktionen
Netzwiederkehrprogramm
2
Raumtemperaturbegrenzung
1
5
Nachtkühlbetrieb
8
Zyklisches Schalten
7
Zeitabhängiges Schalten
6
Gleitendes Ein- / Ausschalten
4
Ereignisabhängiges Schalten
3
h,x geführte Strategie 7)
2
Stellausgabe: Z.B. 3-Punkt = 2 x 2-Punkt
Pro Eingangs-Benutzeradresse
Z.B. Gerätestatus, Zeitschalttab., Sicherheitspkt., Regler, Datei (EN ISO 16484-5)
Falls erforderlich sind bei gemeinsamen (shared) Datenpunkten die Funktionen
im Client mit "A" und die im Server mit "B" zu kennzeichnen (siehe BIBBs)
Rechnen / Optimieren
Arithmetische Berechnung 7)
1
Parameterumschaltung
5
Stellausgabe Pulsweitenmodulation
3
Begrenzung Sollwert / Stellgösse
4
4
4
Stellausgabe 2-Punkt 6)
2
Stellausgabe stetig
1
PI / PID-Regelung
6
Sollwertführung / -kennlinie
5
3
P-Regelung
3
Sicherheits-/ Frostschutzsteuerung
2
Umschaltung 5)
1
Folgesteuerung 5)
3
Motorsteuerung
5
2
Verarbeitungsfunktionen
Regeln
Steuern
Anlagensteuerung
Betriebsstunden-Erfassung
4
Grenzwert gleitend
2
Analoger Eingabewert, Messen
1
Überwachen
Grenzwert fest
5
1
Zählwerteingabe
4
Analoger Ausgabewert, Stellen/Sollwert
3
Binärer Eingabewert, Zustand
2
Analoge Eingabe Messen 2)
1
Binärer Ausgabewert, Schalten
Binäre Eingabe Melden
Abschnitt
Spalte
Binäre Eingabe Zählen
Datenpunkt
Z. B. DP-Name mit Nr.
Analoge Ausgabe Stellen
Zeile Nr.
Anlage
Binäre Ausgabe Schalten / Stellen 1)
Ein- / Ausgabefunktionen
Physikalisch Gemeinsam 3)9)
Befehlsausführkontrolle
Gewerk:
b) Verzögern und c) Unterdrücken von Meldungen
5) Pro Ausgangs-Benutzeradresse
Meldungsbearbeitung 4)
GA-Funktionsliste
6)
7)
8)
9)
3) Nur gemeinsame, kommunikative Datenpunkte
von Fremdsystemen für interoperable Funktionen
4) Pro Eingangs-Benutzeradresse zum a) Zusammenfassen,
Ereigniszählung
Annex A (normativ)
Energierückgewinnung 7)
1) Dauerbefehl: Z.B. 0,I,II=2 BA
Impulsbefehl: Z.B. 0,I,II=3 BA
Stellbefehl: Z.B. Zu-0-Auf=2 BA
Pulsweitenmod.=1 BA
2) Aktiv oder passiv
EN ISO 16484-3
Bemerkungen
ANMERKUNG
Definition 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
8
9
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
Rev. 1
Rev. 2
Rev. 3
Name
Geprüft
Planersteller:
Projekt:
Informationsschwerpunkt:
Datei:
Zeichnungs-Nr.:
Steuerungsbeschr. Nr.:
Blatt Nr.
von:
[Tabelle_ISO-GA-FL-Vorlage-2_050513.xls]
© 1996-2005 ISO/TC205_CEN/TC247_VDI-TGA_GAEB070
Beiblatt D 1 - Beispiel GA-Funktionsliste (fortgesetzt)
HAK
104
Beiblatt D 2 – Adress-Struktur
HAK
105
Beiblatt D 3 - Netzwerkdarstellung
HAK
106
Beiblatt D 4 - Bieterangaben zum Netzwerk
HAK
107
Beiblatt D 5 - Bieterangaben zur Automations-Hardware
HAK
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
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 Systemund 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
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
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
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
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
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 STLBBau 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
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 BenutzeradressenStruktur,
HAK
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äteVordergrund,
- 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
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
Analog-Eingänge (AE) Anzahl ……………………………10
Analog-Ausgänge (AA) Anzahl …………………………….5
Zähl-Eingänge (ZE) Anzahl ………………………………...5
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
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
119
E.2.6
Teilleistungsgruppe (Position) BACnet-Datenschnittstelleneinheit (z. B. Gateway)
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
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
E.2.7
Teilleistungsgruppe (Position) Datenschnittstelleneinheit zur Brandmeldeanlage
TLG: Schnittstellen zu anderen Fabrikaten, Typen, Systemen
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
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 BACnetObjekte 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" BACnetSystems 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
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
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).
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
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
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
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
2
3
4
5
6
C
1
2
3
4
D
1
2
3
HAK
Ein-/Ausgabe- Kommunikationsfunktionen für „gemeinsame“ (shared) Datenpunkte
(Integration auf Automationsebene)
Überwachungsfunktionen (z.B. Grenzwerte)
Steuerungsfunktionen (z.B. Motorsteuerung)
Regelungsfunktionen (z.B. Kaskadenregler)
Rechen- und Optimierungsfunktionen
Ergänzung der GA-Funktionsliste für Funktionsdokumentation und für die
Massenermittlung
Ermitteln der benötigten Management- und Bedienfunktionen
Managementfunktionen (z.B. History)
Bedienfunktionen (Anlagenbild u. Einblendungen)
Management-Kommunikationsfunktionen (Integration für Bedienung oder
Managementebene)
Ergänzung der GA-Funktionsliste für Funktions-Dokumentation (wichtigster
Vertragsbestandteil) und für die Massenermittlung
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
Objektnamen = Datenpunktadressen sollen so lang wie im Projekt nötig, aber so kurz
wie möglich sein (Beispiel VDI 3814-1:2005)
Festlegung, dass die Objektnamen an allen (Bedien-) Stellen im System zur Verfügung
stehen, um eine einheitliche Kennzeichnung zu erreichen; Projektbeschreibung und LVAnlage
(GAEB / VDI Formblatt „Adress-Struktur“)
Festlegung, dass jedes BACnet-Objekt über eine Objektbeschreibung verfügt
Im Objekt-Property „Description“
Festlegung in System-Standardbeschreibung („Vorbemerkung“)
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
a
a,1
a,2
a,3
b
b,1
b,2
b,3
c
c,1
c,2
c,3
c,4
d
d,1
d,2
d,3
e
e,1
f
f,1
f,2
f,3
HAK
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
Anwendung für Darstellung in:
Grafiken
Tabellen (Berichte), (ggf. für Trendaufzeichnung, Ereignisaufzeichnung)
Für Historisierung von Werten
Anwendung für Anlagenbedienung:
Sollwert- und Parameteränderungen
Überwachung
Aufträge („commands“/ früher „Befehle“)
Festlegung der Aktualisierungs- und Aufzeichnungsintervalle
Festlegung, dass alle Zustände der BACnet-Objekt-Properties (z. B. „Eigenschaften“)
lesbar sind und dargestellt werden, Werte (values) mit SI-Einheiten
Festlegung, dass für die Übertragung von Wertänderungen der sogenannte COVMechanismus (Change-of-Value) verwendet wird; (System-Standardbeschreibung)
Festlegung, dass Bediener den Schwellenwert (COV-Inkrement) durch Schreibzugriff
verändern können; (System-Standardbeschreibung)
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)
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)
Festlegung der benötigten Sollwerte als Bedienfunktion
Festlegung der erforderlichen Parametermodifikationen als Bedienfunktion
Festlegung der schreibbaren Properties für die Regler Objekte
(Loop-Object); Standardbeschreibung für Systemsoftware und GA-FL für
Massenermittlung
Festlegung der erforderlichen Peer-To-Peer (oder Quer-) Kommunikation
Datenaustausch zwischen (GA-Funktionsliste „Verarbeitungsfunktionen“)
Kommunikation zwischen "fremden" Automationsstationen ohne Mitwirkung einer
„Leittechnik“- oder Bedienereingriff (aus GA-FL "Verarbeitungsfunktionen")
Festlegung der Managementfunktionen "Langzeitspeicherung" und
"Historisierung"
Festlegung der Anzahl von Funktionen für die Speicherung (nach VDI-3814-Standard)
Festlegung der Aufzeichnungsintervalle (z.B. Anzahl Werte / Std. für
Langzeitaufzeichnung oder History in Datenbank);
(GA-FL: Managementfunktion „Ereignislangzeitspeicherung“ und Beschreibung)
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)
126
Nr.
f,4
Aktivität
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
Festlegung, wie Alarme dargestellt werden sollen
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)
Festlegung, dass eine Alarmquittierung verwendet wird und wie Alarmquittierungen
dargestellt werden, (GA-FL: Verarbeitungsfunktion „Sicherheitssteuerung“, SystemStandardbeschreibung)
Festlegung, dass zu jedem Zeitpunkt eine Alarmübersicht zur Verfügung stehen muss
(Systemsoftware Standardbeschreibung, z.B. GAEB 070)
Festlegung, dass Alarmgrenzen veränderbar sind, falls dies erforderlich ist,
(GA-FL: Bedienfunktionen)
Festlegung von Meldungsklassen und Alarmpriorisierung
(Standardbeschreibung für Systemsoftware - siehe BACnet-Leitfaden)
Festlegung der Eingriffe des Bedieners in die Alarmerkennung (Detektierung),
z.B. Abschalten von Grenzen als Bedienfunktion in der GA-FL.
a
b
c
d
e
f
g
3
a
b
c
d
4
a
5
a
b
c
d
e
HAK
Check
Zeitplan - Sched
Festlegung der benötigten Zeitplanprogramme (GA-FL: Verarbeitungsfunktion „Zeitplan“;
Beschreibung der Systemsoftware - GAEB 070)
Festlegung, dass der Bediener auf Zeitschaltpläne Einsicht hat (Darstellung)
Festlegung, dass der Bediener auf Zeitschaltpläne Zugriff hat (Bedienung)
Festlegung der Anzahl der mind. möglichen Einträge;
(LV-Beschreibung für das System)
Festlegung der Anzahl der benötigten Einträge; (GA-FL Einträge für Massenermittlung)
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)
Festlegung der Anzahl von Datenpunkten für die Trendaufzeichnung
Device- und Netzwerkmanagement – DM
Festlegung, dass der operative Status jeder BACnet-Einrichtung zu jeder Zeit angezeigt
werden kann; (Standardbeschreibung zur Systemsoftware)
Festlegung, dass der Bediener jederzeit alle Properties von jedem BACnet-Objekt
abfragen kann (Standardbeschreibung zur Systemsoftware)
Festlegung, dass Geräte abgeschalten werden können, die fehlerhafte Daten senden;
Standardbeschreibung zur Systemsoftware und BIBB: DM-DCC-A/B
(DeviceCommunicationControl)
Festlegung, dass Uhrzeitsynchronisation über das Netzwerk erfolgt;
Beschreibung zur Systemsoftware (GAEB 070) und BIBB: DM-TS-B
(TimeSynchronization),
oder DM-UTC-A/B (UTCTimeSynchronization)
Festlegung, dass BACnet-Devices (Einrichtungen) ferngesteuert neu gestartet werden
127
Nr.
k,1
k,2
k,3
Aktivität
können, falls erforderlich; (Standardbeschreibung zur Systemsoftware und BIBB: DM-RA/B (Restart)
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)
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)
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)
Festlegung, dass Router die Routing-Informationen automatisch ermitteln und
untereinander austauschen; Beschreibung der Routerhardware
Festlegung, dass für die technische Bearbeitung (Engineering) oder für Diagnosezwecke
das Property „Out-of-Service“ von Analog-, Binär-, Digital-, Regler- und ProgrammObjekten „schreibbar“ sein muss
Mit diesem Vorgang wird der Aktualwert (Present_Value) eines Objektes vom Prozess
entkoppelt (System-Standardbeschreibung)
Festlegung, welche Objekte bei Bedarf dynamisch erzeugt oder gelöscht werden
können,
z.B. für:
- Trendaufzeichnung
- Ereignisaufzeichnung (kommt in der Norm)
- Meldungsklassen
6
Festlegung der IOB für künftige Erweiterungen, je System- oder Produktkopplung
f
g
h
i
j
k
Check
Schritt 3
F
Anforderungen an die Systemfunktionen der Bedien- und
Managementeinrichtungen (Softwarelizenzen)
1
2
Aus bisher aufgestellten GA-Funktionslisten gehen ein Teil der erforderlichen
„Systemfunktionen" hervor, für weitere gilt das STLB-Bau 070 als „Checkliste“
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
2
3
4
HAK
Auswahl - siehe BACnet Leitfaden
Prüfung, ob ggf. vorhandene Netze verwendet werden sollen/können
(z.B. Liegenschafts- oder Büronetzwerk, Raumautomationsnetzwerk)
Festlegung, dass auf allen Netzwerken das BACnet-Protokoll lauffähig ist.
Vorgabe in der Projekt- und Netzwerkbeschreibung
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).
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
129

PDF

Transcrição

Documentos relacionados

EZ Gateway KNX to BACnet German Data Sheet

Klappenmodul KM1.2-ALU-BAC/KM1.2-PE-BAC

Gebäudeautomation mit BACnet® BASautomation

BACnet Europe

Produktinformation: Gebäudeautomation 2016

ElbePark Dresden

PAR 56-Strahler „Alu Profi“

Bedienungsanleitung

Cylon Site Guide v2