BACnet als Erfordernis im militärischen Umfeld und als Chance für mehr Wirtschaftlichkeit

Rupert Fritzenwallner

 

Wenn bestehende Gebäudeautomationsanlagen saniert oder erweitert werden müssen, führen proprietäre Systeme aufgrund des mangelnden Wettbewerbs oft zu erheblichen Mehrkosten bzw. können Energieeinsparungspotenziale teilweise nicht genützt werden. Sollte auch Ihr Unternehmen über viele Automationsstationen verfügen, sollten Sie sich mit BACnet beschäftigen.

 

BACnet und Militär

Auf den ersten Blick mag man sich die Frage stellen, was BACnet und Militär gemeinsam haben.

BACnet ist ein interoperables Protokoll in der Gebäudeautomation (GA). Die GA umfasst die Gesamtheit von Überwachungs-, Steuer-, Regel- und Optimierungseinrichtungen in Gebäuden. Dabei wird unter GA nicht nur das Gebiet Heizung, Lüftung, Klima, Sanitär und Elektro (HLKSE) abgedeckt, sondern auch jene Themen, die dem Bereich Safety - wie z.B. Brandschutz - und dem Bereich Security - wie z.B. Zutrittskontrolle - zuzuordnen sind.

Der rote Faden von BACnet zu Safety- und Security-Management und in weiterer Folge zum Militär kann daher bereits über die Begriffsdefinition hergestellt werden.

Auch die im Kapitel Sicherheit dargestellte Dreiteilung in physische Sicherheit, Netzwerksicherheit und Applikationssicherheit dokumentiert die Bedeutung des Themas für die militärische Nutzung.

Insbesondere aber vom Konzept der umfassenden Sicherheit (Comprehensive Security) lässt sich die Bedeutung von BACnet für das Militär ableiten.

Umfassende Sicherheit im Sinne von Barry Buzan umfasst nicht nur eine enge hoheitliche Sicherheitsdefinition, sondern hat einen ganzheitlichen Ansatz, der auch privatwirtschaftliche Aufgaben sowie sozioökonomische Faktoren und Aspekte berücksichtigt.1)

Auf diese ganzheitliche Sichtweise wurde auch in zwei anderen Artikeln des Autors einerseits zum Thema „Corporate Security Management“2) und andererseits zum Thema „Risikomanagement“3) hingewiesen.

Der Zusammenhang von „Cyber Security“ und BACnet wird in diversen Forschungsarbeiten wie z.B. einer Arbeit vom Fraunhofer Institut für Kommunikation, Informationsverarbeitung und Ergonomie thematisiert.4)

 

Ausgangssituation

Das Österreichische Bundesheer (ÖBH) als großer Immobilieneigentümer mit Hunderten Gebäudeautomations-Systemen und Tausenden Automationsstationen (AS) stand vor der Herausforderung, ein Konzept

- zum Tausch veralteter herstellerspezifischer (proprietärer) Systeme,

- zur Optimierung der Beschaffungs- und Betriebskosten,

- zur Verbesserung der energetischen Steuerung,

- zur Steigerung der Energieeffizienz und

- zur Erhöhung der Sicherheit

zu entwickeln und im Rahmen eines Pilotprojekts zu evaluieren.

Neben der zentralen Steuerung proprietärer Systeme liegt der Schwerpunkt auf der Konzeption einer BACnet-basierenden interoperablen Lösung.

Building Automation and Control Networks (BACnet) hat seit der ersten Veröffentlichung im Jahr 1995 und der Anerkennung als internationale und europäische Norm im Jahr 2003 einen weltweiten Siegeszug als herstellerneutrales Kommunikationsprotokoll der Gebäudeautomation angetreten. EN-Normen sind in den nationalen Normenbestand zu übernehmen. Daher gibt es in Österreich die ÖNORM EN ISO 16484-5:2014 „Systeme der Gebäudeautomation - Teil 5: Datenkommunikationsprotokoll“.

 

Lösungsansatz

In der ersten Projektphase wurden in einem „Top Down-Approach“ aufbauend auf der Immobiliendatenbank (IDB) des ÖBH ein „Energielagebild“ entwickelt, Prognosen des Energieverbrauchs erstellt und Energieausweise für ca. 2.000 Gebäude automationsunterstützt berechnet.5)

 

In der zweiten Projektphase werden in einem „Bottom Up-Approach“ das Submetering zur Erfassung des gebäudebezogenen Energieverbrauchs und die Optimierung der Gebäudeautomation (GA) zur besseren Steuerung des Energieeinsatzes durchgeführt.

 

Die Optimierung der GA unter dem Arbeitstitel „zentrale Gebäudeautomation“ (zGA) wird nachstehend beschrieben, wobei neben den Ergebnissen auch die Probleme thematisiert werden.

 

Pilotprojekt „zentrale Gebäudeautomation“

Aufgrund einer Analyse des Ist-Standes wurde Optimierungspotenzial für die GA in den Bereichen

- keine einheitliche Bereitstellung der Visualisierung und keine zentralen Softwareupgrades,

- redundante Arbeitsplatzinfrastruktur für Büroanwendungen und Gebäudeautomation,

- fehlende Interoperabilität und davon abgeleitet monopolistische Angebotsstrukturen,

- unzureichende infrastrukturelle Sicherheitsmaßnahmen und Applikationssicherheit,

- fehlende Prognosefähigkeit und unzureichende Energieeinsparung,

- keine standardisierte Bilderstellung und -dynamisierung sowie

- zu hohe Kosten der Gebäudeautomation

gesehen.

Aufbauend auf der Analyse der Optimierungspotenziale wurden nachstehende sechs Zielfelder für das Pilotprojekt zGA wie folgt definiert:

- Planung,

- Funktionalität,

- Wirtschaftlichkeit,

- Interoperabilität,

- Sicherheit,

- Betrieb.

Im Sinne der angeführten Ziele wurde eine Systemarchitektur entwickelt, die eine Zentralisierung des Betriebs der Anlagen, WEB-fähige Visualisierungs- und Managementwerkzeuge, interoperable Komponenten zumindest auf Automations- und Managementebene sowie die Nutzung der Standardarbeitsplätze im Heeresbaunetz gemäß folgender Grafik vorsieht:

 

Building Automation and Control network (BACnet)

BACnet ist das Protokoll für Interoperabilität und offene Kommunikation in der Gebäudeautomation.

Die nachstehenden Ausführungen berücksichtigen die Protokoll-Revision 1.12 (Version 1, Revision 12) von BACnet. Die Norm wird ständig weiterentwickelt und beschreibt in Rev. 1.12 folgende „Elemente“ des Kommunikationsprotokolls:

- acht Netzwerkoptionen (network options) wie z.B. BACnet/IP, MS/TP, ZigBee etc.;

- acht Gerätetypen (device types) wie z.B. BACnet Advanced Workstation (B-AWS), BACnet Building Controller (B-BC) etc.;

- fünf Interoperabilitätsbereiche (IOBs): gemeinsame Datennutzung (Data Sharing - DS), Alarm- und Ereignismanagement (Alarm & Event Management - AE), Zeitplan (Scheduling - SCHED), Trendaufzeichnung (Trending - T) Device- und Netzwerkmanagement (Device & Network Management - DM),

76 Interoperabilitätsbausteine (BACnet Interoperability Building Blocks - BIBBs) wie z.B. „gemeinsame Datennutzung Lese-Eigenschaft Gerät A“ (Data Sharing Read Property A - DS-RP-A) etc.,

58 Dienste (services) zur Kommunikation zwischen Devices (Lesen, Schreiben, Anlegen und Löschen von Objekten, Abonnieren von Werten etc.);

- 51 Objekttypen (object types) wie z.B. Analogeingabe (Analog Input - AI), Binärausgabe (Binary Output - BO), Betriebskalender (Calendar - CAL), Ereignisaufzeichnung (Event Log - ELOG) und evtl. proprietäre Objekttypen etc.,

351 Datenelemente (properties) wie z.B. Objektname, Wert, Alarmgrenze, Status etc., wobei abhängig vom Konformitätscode die Informationen der Datenelemente gelesen werden (read), geschrieben werden (write) oder optional sind,6)

Datentypen (data types) wie z.B. CharacterString, Boolean, Unsigned, Real etc., die den Properties zugeordnet werden,

Kategorien von properties (lesen, schreiben, funktionsabhängig optional und proprietär);

- BACnet Web Services Interface (XML-Datenformate, SOAP, http);

- Fehler-, Zurückweisungs- und Abbruchcodes (Fehlerklassen).

Es empfiehlt sich, die schnelle Weiterentwicklung von BACnet zu beobachten und deren Ergebnisse zu berücksichtigen. Die American Society of Heating, Refrigerating and Air-Conditional Engineers (ASHRAE) hat seit 1987 das Protokoll mit internationaler Besetzung als Richtlinie Nr. 135 entwickelt. 1995 wurde es von ANSI in Nordamerika als nationale Norm übernommen. ASHRAE hat von ISO und CEN den Auftrag, BACnet weiter zu pflegen und zu ergänzen.

 

Die Tabelle zeigt die unterschiedlichen Entwicklungsgeschwindigkeiten bezüglich

- der Entwicklung neuer Ergänzungen (Addendas) durch die ASHRAE,

- der Umsetzung dieser Addendas in ISO-, CEN- und ÖNORMen und

- der verfügbaren zertifizierten BACnet-Produkte.

Da auch etablierte Hersteller säumig sind, was die Umsetzung aktueller BACnet-Revisionen betrifft, auch wenn die Voraussetzungen (Prüfkriterien) erfüllt sind, kann nur dringend empfohlen werden, bei der Planung von Neubeschaffungen sowohl für die AS als auch für die MBE (Management Bedieneinrichtung) auf die aktuellen BACnet-Revisionen zu setzen und zertifizierte Produkte einzusetzen.

BACnet Revision 1.12 wird derzeit als Minimalforderung an alle Devices, insbesondere auch an die MBE, gesehen. Nachträgliche Änderungen sind mit hohem Aufwand und mit hohen Kosten verbunden, weshalb auf die Konformität mit möglichst aktuellem Standard für alle eingesetzten Devices geachtet werden sollte.

 

Netzwerktypen

In der BACnet-Norm sind folgende acht Netzwerkoptionen vorgesehen:

- Ethernet (ISO/IEC 8802-3),

- BACnet IP v4 (BACnet Annex J),

- BACnet IPv6 (BACnet Annex X),

- ARCNET (ATA/ANSI 878.1),

- MS/TP (EIA RS-485 und Ergänzung in der BACnet-Norm),

- PTP (EIA RS-232C),

- LonTalk (EIA/CEA 709.1-B und EN 14908),

- ZigBee (IEEE 802.15.4).

Als wichtigste Netzwerke sind MS/TP, BACnet/IP (nach Annex J) anzuführen, für die es die meisten Geräte gibt.

 

Gerätetypen

Der BACnet-Standard sieht folgende acht Gerätetypen (device types) vor:

- Management- und Bedienstation (BACnet Advanced Operator Workstation - B-AWS),

- Bedien- und/oder Managementeinrichtung (BACnet Operator Workstation - B-OWS),

- Bediengerät (BACnet Operator Device - B-OD),

- Automationsstation (BACnet Building Controller - B-BC),

- konfigurierbare Automationseinrichtung (BACnet Advanced Application Controller - B-AAC),

- parametrierbare Automationseinrichtung (BACnet Application Specific Controller - B-ASC),

- netzwerkfähiges Schalt- und Stellgerät (BACnet Smart Actuator - B-SA),

- netzwerkfähiger Fühler (BACnet Smart Sensor - B-SS).

Als wichtigste Geräte sind auf der Leitsystemebene die B-AWS und auf der Automationsebene der B-BC anzuführen.

 

Dienste

BACnet-Dienste (Services) dienen der Übertragung von Daten (Informationen in den Properties der Objekte) z.B. durch Lesen, Schreiben, Abonnieren, Anlegen, Löschen etc. in Management- und Bedieneinrichtungen (MBE), Automationseinrichtungen (z.B. AS) und Feldgeräten. Bestätigte (confirmed - C) und unbestätigte (unconfirmed - U) BACnet-Dienste werden in sieben Gruppen wie folgt unterschieden:

- Alarm- und Ereignis-Dienste,

- Objektzugriffs-Dienste,

- Gerät- und Netzwerkmanagement-Dienste,

- Virtual Terminal-Dienste,

- Fehler-, Zurückweisungs- und Abbruch-Codes,

- Prozeduren (Datensicherung, Priorisierung etc.),

- WEB-Dienste und XML-Datenformate.

Im BACnet-Standard sind beispielsweise mehrere Mechanismen vorgesehen, um Ereignisse (events) zu behandeln:

- ereignisorientierte Datenübertragung (Change of State und Change of Value reporting (COV)),

- objektinternes Melden (intrinsic reporting),

- regelbasiertes Melden (algorithmic change reporting).

Ein Ereignis kann der Wechsel eines Zustands, ein spezieller Betriebszustand, die Änderung eines Messwerts oder ein Ausnahmezustand sein. Die Entscheidung, welche Form des Meldens wofür zu verwenden ist, ist Aufgabe des Planers. Wer wann mit welcher Priorität eine Meldung erhält, wird im Meldungsklassen-Objekt (Notification Class, NC) festgelegt. Das Ereignisregistrierungsobjekt (Event Enrollment) dient dazu, Objekte in Geräten zu überwachen, die selbst nicht melden können, z.B. kein „Intrinsic Reporting“ unterstützen. Zur Umsetzung von Projekt-Anforderungen sind eine Vielzahl von Objekttypen und Diensten im BACnet-Standard verfügbar. Der Planer muss daher festlegen, welche davon wie genutzt werden, um Interoperabilität zwischen Geräten unterschiedlicher Hersteller zu ermöglichen.

 

Objekte und Properties

Von den 51 in Rev. 1.12 verfügbaren BACnet-Objekttypen sind im Regelfall für eine HLKSE-Anlage ca. 25 Objekttypen samt entsprechenden Datenelementen (Properties) erforderlich. Die weiteren Properties wurden für die Aufgabenstellungen Brandmeldetechnik, Zutrittskontrolle und Sonderanwendungen geschaffen. Es ist darauf zu achten, dass ein Hersteller auch die als „optional“ gekennzeichneten Properties in seinem System wahlfrei umgesetzt hat, denn diese werden in Projekten je nach Anwendung benötigt (z.B. Grenzwerte, Quittierpflicht, Wochenplan). Grundsätzlich sollte das Property„Beschreibung“ (description) immer gefordert werden.

In der Herstellererklärung „Protocol Implementation Conformance Statement“ (PICS) wird für die Objekttypen die unterstützte Funktionalität wie folgt dokumentiert:

- unterstützte Objekte (supported - S),

- dynamisches Anlegen (dynamic object creation - OC),

- dynamisches Löschen (dynamic object deletion - OD),

- Gruppenauftrag (object commandable - CMD),

- Außer Betrieb (out of service writeable - OOS),

- Datenübertragung (Change of Value) - COV),

- Meldung (intrinsic/algorithmic change reporting - IR/AR).

Das Festlegen der im Projekt erforderlichen optionalen Properties und das Ausschließen proprietärer Properties als Ersatz für die genormten ist ein wichtiger Schritt zur faktischen Umsetzung von Interoperabilität. Proprietäre Objekttypen und Properties sind nach Norm (ausschließlich) erlaubt für z.B. Engineering-Tools des jeweiligen Herstellers oder für kundenspezifische Sonderfälle. Diese sind dann nicht interoperabel mit Produkten anderer Hersteller. Die Festlegung der im Projekt erforderlichen Objekte und auch aller zugehörigen Properties ist unverzichtbar, um beispielsweise Automationseinrichtungen und MBE unterschiedlicher Hersteller innerhalb eines Systems und diesbezügliche Kostenvorteile bei Erweiterungen und Renovierungen nutzen zu können.

Hans Kranz formuliert treffend: „Optionen sind der größte Feind der Interoperabilität“.7)

Das PICS, das jeder Hersteller zertifizierter Gerätetypen anbietet, dient der Kontrolle, ob die Geräte (devices) die im Projekt geforderte Funktionalität (Dienste, Objekte, Properties etc.) zumindest theoretisch erfüllen.

Im PICS wird für jedes Property der Konformitätscode (conformance code) angegeben, welche Möglichkeiten, wie:

- lesbar immer vorhanden (read - R),

- lesbar und schreibbar immer vorhanden (write - W),

- optional vorhanden (optional - O, schreib- oder lesbar),

- proprietär vorhanden (proprietär - P, schreib-oder lesbar)

im Device implementiert ist und ob es Restriktionen gibt. Dabei ist zu berücksichtigen, dass nicht alle optionalen Properties durch alle Hersteller auch unterstützt werden (lesbar oder schreibbar). Schreibbare Properties können mit entsprechenden BACnet-Diensten verändert werden, z.B. für Schalt- und Analog-Ausgänge.

 

Um den Anwendern die Prüfung zu erleichtern, welcher BACnet-Revision ein Gerät entspricht und welche Netzwerkoptionen, Objekttypen, (optionale) Properties und Dienste etc. das Device unterstützt, hat die „BACnet International“ (BI) (http://www.bacnetinternational.org/) die BACnet Testing Laboratories und das BTL-Logo, das im Wesentlichen der Zertifizierung in Europa entspricht, geschaffen. Grundlagen der Prüfung sind die ÖNORM EN ISO 16484-6 und die darauf aufbauend entwickelten Prüfkriterien der BI-BTL-WG (Working Group).

Unter der URL http://www.big-eu.org/produkte/zertifizierte-produkte/ können die Protocol Implementation Conformance Statements (PICS) von derzeit 208 und schnell wachsenden gelisteten und überprüften BACnet-Geräten (devices) mit Stand 12.10.2015 heruntergeladen werden. Diese wenige Seiten umfassenden Dokumente geben einen schnellen Überblick, welche der beschriebenen Funktionen durch das jeweilige Gerät (Device) theoretisch erfüllt werden.

 

Wichtig ist dabei, darauf zu achten, dass für alle genutzten Geräte (devices) wie z.B. MBE und AS das Mindesterfordernis BACnet Revision 1.12 erfüllt wird. Wenn Hersteller erklären, dass die vor fünf Jahren definierten Funktionalitäten nicht benötigt werden, sollte man kritisch hinterfragen und überlegen, welche erheblichen Nachteile für den Betrieb (Anlegen und Löschen von Objekten, kein aktueller Zeichensatz etc.) dadurch entstehen können.

Auch sind die Beschaffungskosten der Geräte der kleinere Kostenblock, hingegen Planung, Engineering, Bilderstellung, Bilddynamisierung etc. der größere Teil der Gesamtkosten, die bei Umstellung auf neue BACnet-Revisionen gegebenenfalls nochmals anfallen.

 

Planung des Pilotprojekts

Die Bedarfsplanung und die Festlegung der erforderlichen (genormten) GA-Funktionen sowie die davon abgeleitete Vorgabe der zu nutzenden BACnet-Objekte, Properties und Dienste stellen die zentralen Herausforderungen zur Umsetzung einer Multi-Vendor-Anlage mit BACnet dar.

Die Planung der GA als automatisierter Betrieb der Gewerke Heizung, Lüftung, Klima, Sanitär und Elektro (HLKSE) mittels MSR-Technik (Messen, Steuern, Regeln) ist an sich schon herausfordernd, besonders aber mit interoperablen Systemen unterschiedlicher Hersteller.

Voraussetzung ist, dass der Auftraggeber (Bauherr, Nutzer) seine Ziele wie Energieeinsparung, Nutzung, Komfort etc. klar formuliert und dass der GA-Planer über ein ausreichendes Maß an Fachwissen und Erfahrung zur Umsetzung in den Bereichen HLKSE, MSR, GA, Informations- und Kommunikationstechnik (IKT), der globalen GA-Normenserie 16484 und insbesondere BACnet verfügt.

Die Komplexität der Aufgabe steigt, wenn bestehende Systeme, wie z.B. proprietäre GA-Systeme mit Gateways und IT-Infrastrukturen (Netzwerk, Sicherheit, Office-Systeme etc.), in die neue Lösung zu integrieren sind.

 

Bedarfs- und Umsetzungsplanung

Die Definition der funktionellen Anforderungen an die GA im Hinblick auf den geforderten Komfort und die Energieoptimierung (Bauherrenvorgaben) ist gemäß ÖNORM EN ISO 16484-3 basierend auf den Mindestanforderungen an die Hardware nach ÖNORM EN ISO 16484-2 und anhand

- der Automationsschemata,

- der GA-Funktionslisten (GA-FL mit Benutzer-Adress-Schlüssel (BAS) und den BIBBs),

- der GA-Funktionsbeschreibungen, ggf. Zustandsgraph (VDI 3814-6) sowie

- des Lastenhefts (mit BACnet-Vorgaben nach ÖNORM EN ISO 16484-5)

durchzuführen.

Die Erstellung der GA-Funktionsliste, aufbauend auf den Automationsschemata als Grundlage für die qualitative und quantitative Festlegung der Funktionen und ihrer Datenpunkte, ist für viele GA-Planer bereits eine große Herausforderung, wenn sie nicht geschult sind und kein Tool benutzen. Der Prozess zur Ableitung von GA-Funktionslisten aus Automationsschemata kann durch Softwareprodukte automatisiert werden.8) Die Nutzung der diesbezüglichen Leistungsgruppen der standardisierten Leistungsbeschreibung Haustechnik (LB-HT)9) mit dem Datenkommunikationsprotoll BACnet ist zu empfehlen.

Gemäß ÖNORM EN ISO 16484-3 werden anlagen- und anwendungsspezifische Funktionen und Datenpunkte in der GA-Funktionsliste (GA-FL) für ein Projekt festgelegt. Die GA-FL dient der herstellerunabhängigen Beschreibung der Automationsanforderungen und kann für Ausschreibungen, Kostenkalkulationen und Abrechnungen genützt werden. Neben dem Mengengerüst der Funktionen für die jeweiligen Datenpunkte in der Ausschreibung soll daher auch die Basis für die Abrechnung und die Kontrolle der ausgeführten Funktionen anhand der interoperablen Elemente in der Planungsphase (GA-FL) und in der Umsetzungsphase (Engineering Data Exchange-File (EDE)) wie folgt abgedeckt werden:

 

 

 

Die 1:1-Beziehung zwischen Planung und Umsetzung bedarf einiger Konkretisierungen im Bereich der GA-FL und Vorgaben für die Erstellung der EPICS-Datei (EDE-File) gemäß Download-Muster von der URL http://www.big-eu.org/service/downloads/.

Im ersten Schritt sind daher Automationsschemata für die einzelnen Bauteile der Gebäudeautomation (GA) zu erstellen:

 

 

 

Zur Sicherstellung der in der vorangeführten Tabelle geforderten 1:1-Beziehung zwischen Planung und Umsetzung müssen in der GA-FL neben den Funktionen auch die Datenpunktadressierungen und die BACnet Interoperability Building Blocks (BIBBs) erfasst werden.

Ein wichtiger Punkt für die Bearbeitung der GA-FL ist daher die Definition und Vorgabe der Datenpunktadressen. Die einheitliche Struktur der Datenpunktadressierung (Benennung) für physikalische und virtuelle Datenpunkte ist eine wesentliche Voraussetzung für interoperable Gebäudeautomationssysteme im ÖBH.

Die Datenpunktadressierung im ÖBH besteht aus

- der Ortskennung (Liegenschaft und Gebäude),

- der BACnet-Herstellerkennung,

- der Anlagenkennung,

- der Bauteilkennung,

- der Datenpunktkennung sowie

- einem sprechenden Freitext

und wird durch Strukturvorgaben, Benennungsvorgaben und Abkürzungen im Detail festgelegt.

Zwischen den relevanten Planungsdokumenten bestehen folgende Zusammenhänge:

 

 

Ein Muster der GA-FL sieht wie folgt aus:

 

 

 

 

 

 

 

 

 

 

 

 

Die GA-Funktionsliste ist unterteilt in die

- Datenpunktadressierung (BACnet BAS),

- Bezeichnung der Funktionen,

- Ein-/Ausgabefunktionen (physische und kommunikative, gemeinsame Datenpunkte),

- Verarbeitungsfunktionen (Überwachen, Steuern, Regeln, Rechnen),

- Managementfunktionen (Kommunikation, Betriebsdatenspeicherung),

- Bedienfunktionen und

- Anmerkungsspalte (BIBBs).

Zur Abbildung der Datenpunktadressierung (Benutzeradressschlüssel/BAS) muss pro Datenpunkt eine eigene Zeile angelegt werden. Daher werden die einzelnen Funktionen teilweise in mehrere Zeilen untergliedert, wie aus dem Beispiel ersichtlich ist.

Da die Datenpunktadressierung des ÖBH in den Spalten 24 bis 30 das BACnet-Objekt enthält, muss der Planer über diesbezügliches Know-how verfügen. Dies gilt auch für die letzte Spalte der GA-FL, wo die BACnet-Objekte bzw. BACnet Interoperability Building Blocks (BIBBs) eingetragen werden sollten.

Diese Interpretation der GA-FL ist erforderlich, wenn später der Zusammenhang zwischen Planung und Realisierung des BACnet-Systems hergestellt werden soll.

Aus juristischer Sicht erscheint es problematisch, wenn der Planer diese Leistungen bereits durch einen der Anbieter von GA-Systemen durchführen lässt bzw. wenn die Umsetzung der GA-Funktionen via BACnet nicht schon in der Planungsphase im Detail festgelegt wird, sondern überhaupt erst im Zuge der Bauphase einem vom Auftragnehmer eingesetzten Tool zur „Übersetzung“ der Datenpunkte in erforderliche BACnet-Elemente überlassen wird.

In den Automationsschemata werden HLK-Teilsysteme wie Heizkreise, Trinkwassererwärmung, Abluftanlagen etc. definiert, in der GA-FL werden die erforderlichen Funktionen samt den zugehörigen Datenpunktadressierungen erfasst. Für jedes Teilsystem ist ein eigenes Tabellenblatt der GA-FL aus dem Automationsschema zu erstellen.

Nur wenn diese Vorgaben berücksichtigt werden, kann ein automatisierter Abgleich mit dem EDE-File (Engineering Data Exchange), welches dann zusätzlich die Device-Adressen, die Zustandstexte und phys. Einheiten enthält, hergestellt werden.

Während dieser Zusammenhang bei physikalischen und gemeinsamen Datenpunkten (Spalten 2 bis 11 der GA-FL) augenscheinlich ist, erfordert die Zuordnung von Funktionen zu berechneten, abgeleiteten logischen (oder virtuellen) Datenpunkten zu BACnet-Funktionen mittels der GA-FL einschlägiges Know-how.

Für den Abgleich mit der realisierten BACnet-Funktion sind die unterschiedlichen Philosophien der einzelnen Hersteller wie folgt zu berücksichtigen:

- automatisiertes, durch die MBE initiiertes Auslesen aller BACnet-Objekte und Properties aus der AS (EDE-File, EPICS),

- automatisiertes, durch die MBE initiiertes Auslesen der erforderlichen BACnet-Objekte und Properties aus der AS (EDE-File, EPICS),

- manuelle Übernahme aller BACnet-Objekte und Properties aus dem Engineering-Tool in die MBE (EDE-File, EPICS),

- manuelle Übernahme der in der MBE erforderlichen BACnet-Objekte und Properties aus dem Engineering-Tool in die MBE (EDE-File, EPICS),

- manuelle Übernahme aller BACnet-Objekte und Properties aus der AS in die MBE (EDE-File, EPICS),

- manuelle Übernahme der in der MBE erforderlichen BACnet-Objekte und Properties aus der AS in die MBE (EDE-File, EPICS),

- manuelle Übernahme der erforderlichen Funktionalitäten über eine proprietäre Schnittstelle vom Projektierungstool in die AS,

- manuelle Übernahme der erforderlichen Funktionalitäten über eine proprietäre Schnittstelle von der AS in die MBE.

Gefordert wird eine durchgängige Lösung von der Planung zur Programmierung der Automationsstationen bis hin zu Management und Bedieneinheit.

 

Proprietäre Lösungen werden bei identem Hersteller auf AS- und MBE-Ebene bevorzugt, sollten aber im Hinblick auf Multi Vendor-Lösungen und spätere Erweiterungen/Umbauten keinesfalls akzeptiert werden.

Wenn keine direkte Auslesung aller Daten der AS durch die MBE möglich ist, sollte jedenfalls eine EDE-Datei (oder ein Projekt-EPICS) eingefordert und die Umsetzung der Planungsanforderungen überprüft werden.

Die EDE-Datei ist eine Empfehlung der BIG-EU, die aus dem ersten großen Multi Vendor-Projekt „Technik-Verbund-Parlamentsbauten in Berlin“ entstanden ist. Die EDE-Datei dient als Unterstützung für den Datenaustausch zwischen Auftragnehmern.10) Dass diese auch Probleme aufwerfen kann, zeigt das konkrete Projekt, wo bei zwei Automationsstationen die EDE-Datei (Engineering Data Exchange) einmal 80 Zeilen, einmal über 600 Zeilen und beim dritten Versuch realistische 432 Zeilen umfasst hat.

Die Projektierungs- und Engineering-Tools, die zur einfachen, rationellen Umsetzung proprietärer Lösungen entwickelt wurden, sind dann problematisch, wenn mit ihnen ein BACnet-Projekt realisiert wird. Bei Multi Vendor-Systemen müssen die Anforderungen des Lastenhefts, der GA-FL und der Funktionsbeschreibung erfüllt werden. Auch wurden im Zuge der Überprüfung der BACnet-Realisierung Fehler in den Datenpunkten gefunden, sodass der Prozess wiederholt werden musste. Die Tools potenzieller Auftragnehmer sind auf deren Eignung für Multi-Vendor-Projekte zu prüfen, ggf. durch Referenzprojekte.

Die Anzahl der BACnet-Datenpunkte, deren Informationen als „gemeinsame Datenpunkte“ zwischen AS und MBE ausgetauscht werden, kann auch von wirtschaftlicher Bedeutung sein, da die Abrechnung vielfach über Datenpunkte erfolgt. Ob physikalische, gemeinsame oder auch virtuelle bzw. logische Datenpunkte, die in der Kommunikation zwischen AS und MBE erforderlich sind, verrechnet werden, hängt von den vertraglichen Regelungen ab. Sinnvollerweise erfolgen die Ausschreibung und die Abrechnung nach der standardisierten Leistungsbeschreibung Haustechnik (LB-HT) und den diesbezüglich vorgesehenen Leistungsgruppen (LG) 84 bis 89.

Wie die Gebäudeleitsysteme (MBE) die Datenpunkte proprietär verarbeiten und ermitteln (Priority Array, Priority Reset etc.) und wie die Datenpunkte oder die „Variablen“ der Datenpunkte gemäß den Lizenzen (2.000 DP, 5.000 DP bzw. „Tags“ etc.) ermittelt werden, ist auch eher der Kategorie „Black Box“ zuzuordnen und hat mit Normung, Standards etc. nichts zu tun.

Voraussetzung für funktionierende Lösungen sind Geräte, die gewisse Eingangsvoraussetzungen erfüllen, wie z.B. nach BACnet-Norm zertifizierte Geräte, die anhand der PICS beurteilt wurden und deren konkrete Anwendung im Projekt im Lastenheft und im Leistungsverzeichnis der Ausschreibung zu spezifizieren ist.

 

Eingangsvoraussetzungen

Die Anwendung zertifizierter BACnet-Geräte gemäß ÖNORM EN ISO 16484 Teil 5 und Teil 6 ist eine notwendige, aber nicht hinreichende Voraussetzung zur Einbindung von Geräten unterschiedlicher Hersteller.

Da gemäß dem Standard verpflichtende, optionale und auch proprietäre Objekte, Properties und Dienste zulässig sind und manchmal mehrere Möglichkeiten bestehen, eine Funktion umzusetzen, müssen bereits in der Planungsphase die anzuwendenden BACnet-Objekte, deren Namen, Properties, Merkmale und die Dienste exakt festgelegt werden.

 

 

 

Clients (z.B. die MBE) fordern Daten wie Zustandswerte gemäß BACnet-Semantik von einem Server (z.B. AS) anhand von Diensten (Aktualisieren, Lesen, Schreiben) an.

Die Festlegung der mindestens erforderlichen BACnet-Revision für alle benötigten Geräte ist eine erste Grundsatzentscheidung über Erfolg oder Misserfolg im Projekt. Die BACnet Advanced Workstation (B-AWS = Gebäudeleittechnik) und die BACnet Building Controller (B-BC = Automationsstation) sollten zumindest der BACnet-Revision 1.12 entsprechen, wenn ein Zeichensatz mit Umlauten, ein zentrales Backup und Restore etc. erforderlich sind (aktuell sind die Anforderungen an BACnet-Revision 1.17 definiert, und erste Zertifizierungen liegen für BACnet-Revision 1.14 vor). Der Nachweis der Erfüllung dieser Anforderungen wird in Europa üblicherweise über Zertifikate, im Rest der Welt über die Herstellererklärung und das BTL-Logo erbracht.

Grundlage des BTL-Logos bzw. der Zertifikate sind die vom Hersteller angegebenen Protocol Implementation Conformance Statements (PICS), die u.a. Auskunft über die möglichen BACnet Interoperability Building Blocks (BIBBs) geben. Diese zeigen auf, welche Anforderungen die Geräte erfüllen.

Ein BTL-Logo dokumentiert, dass die angegebenen BACnet-Objekte, Properties und Dienste der jeweiligen BACnet-Revision theoretisch erfüllt werden. Hinsichtlich der optionalen Objekte, Properties und Dienste muss für alle erforderlichen Geräte (B-AWS, B-BC) geprüft werden, ob alle im speziellen Projekt geforderten Funktionen auch unterstützt werden.

 

Ergänzend zu den BACnet-Konformitätsprüfungen existieren in Deutschland Empfehlungen vom Arbeitskreis Maschinen- und Elektrotechnik staatlicher und kommunaler Verwaltungen (AMEV) mit BACnet 2011, BACnet in öffentlichen Gebäuden Version 1.2 betreffend die Mindestausstattung (verpflichtende und optionale Funktionen) der BACnet-Geräte. Die AMEV-Profile A und B definieren unterschiedliche Anforderungslevels in der Gebäudeautomation.

Testate für die AMEV-Profile A und B existieren nur für die Automationsstation (AS), nicht jedoch für die Management- und Bedieneinheit (MBE). Ein diesbezüglicher Nachweis ist derzeit nur durch eine Selbsterklärung der Hersteller möglichDurch das Festlegen der BACnet-Revisionsnummer, ggf. die Festlegung der AMEV-Profile für MBE und AS sowie die Prüfung der dem BTL-Logo oder den Zertifikaten zugrunde liegenden PICS und BIBBs ist ein Schritt in Richtung Interoperabilität getan und geklärt, ob die Geräte der unterschiedlichen Hersteller die Mindestanforderungen des Projekts, d.h. die Eingangsvoraussetzungen zumindest theoretisch erfüllen. Dazu ist eine kompetente Beratung dringend erforderlich.

 

BACnet-Lastenheft

Die Ergebnisse der Bedarfsplanung finden ihren Niederschlag im Lastenheft, das bei Multi Vendor-Anlagen unter BACnet zusätzlich an Bedeutung gewinnt und bei dessen Erstellung bereits gute BACnet-Kenntnisse bzw. eine entsprechende fachkundige Unterstützung von Vorteil sind, wobei die Zahl BACnet-kundiger GA-Planer in Österreich noch sehr gering ist. Hier wird eine herstellerneutrale Schulung durch bekannte Experten oder in den verfügbaren Institutionen, z.B. beim VDI (für Planer) oder DIAL (für Errichter), empfohlen.

Um die Auftragnehmer aktiv in das Projekt einzubinden, sollten diese daraus ein Pflichtenheft erstellen, das den Vorgaben des Lastenhefts entspricht und durch den Auftraggeber/Planer freizugeben ist.

Im Lastenheft sind Vorgaben v.a. zu nachstehenden Themen erforderlich (Grundlage ist die ÖNORM EN ISO 16484-1):

- Rahmenbedingungen (Einbindung proprietärer GA, Netzwerk, Sicherheit etc.),

- Aufbau und funktionale GA-Anforderungen im gegebenen Umfeld (v.a., welche GA-Funktionen wo zu implementieren sind), Zuweisung von Funktionen zu Teilsystemen,

- Netzwerke, BACnet-Revisionsnummer bzw. AMEV-Profile, BACnet Device Profile als Mindestanforderung, wenn spätere Erweiterungen vorgesehen sind,

- die für eine Umsetzung erforderlichen BIBBs, BACnet-Objekte und Properties, inklusive einer Vorgabe, dass proprietäre BACnet-Objekte und Properties die genormten nicht ersetzen dürfen,

- Zeichensatz UTF-8 für Umlaute und Sonderzeichen,

- Benutzeradressierung (Benutzeradressschlüssel (BAS)) von Datenpunkten,

- Adressierung und Identifyer von Objekten, insbes. Deviceobjekten (und deren Namen), BACnet-Netzwerknummern, IP-Adressen, Subnetzadressen,

- Meldungs- und Informationsmanagement (Meldungsklassen und Prioritäten, Meldungsübertragung und -weiterleitung, Quittierpflicht, physikalische Einheiten im SI-System, Zustandstexte, Trendobjekte, Historisierung etc.) und Command-Prioritäten (Priority Array) für Schalt- und Stellaufträge, NC-Objekte,

- Betreibervorgaben (Vorgaben zur Bilderstellung bzw. Visualisierung und Dynamisierung),

- Betreibervorgaben für das Berichtswesen (Statistik- und Energieprotokolle, Druckformate),

- Sicherheit (Zutrittssicherheit zu physikalischen Komponenten, Netzwerksicherheit, Applikationssicherheit und gestaffelte Zugriffsberechtigungen),

- Vorgabe eines ständig mitlaufenden, speichernden Protokoll-Analysators wegen der Gewährleistungszuordnung und des Sabotagenachweises,

- Vorgaben für die Schulung und Einweisung des Personals,

- Umsetzungsprozess (Rollen und Verantwortlichkeiten, Dokumentation etc.).

Die neutrale und konkrete Darstellung der Mindestanforderungen und deren BACnet-Umsetzung ermöglichen vergleichbare Angebote, mehr Konkurrenz, Qualitätsvergleiche und auf Dauer günstigere Preise.

 

Wenn durch den Bauherrn oder Planer kein detailliertes Lastenheft erstellt wurde, kann auch keine Interoperabilität erwartet werden. Wenn der Planer die notwendigen Forderungen in den Ausschreibungsunterlagen nicht konkret beschreibt, kommt kein gültiger Vertrag zustande, wie durch Gerichtsurteile dokumentiert ist.

 

Evaluierung des Pilotprojekts

Die Evaluierung des Pilotprojekts zGA erfolgt mit der Nutzwertanalyse (NWA) nach ZANGEMEISTER.11) Dazu wurde eine Zielehierarchie entwickelt und durch mehrere Beteiligte eine Gewichtung der Ziele für die erste Zielhierarchie in mehreren Durchgängen mit nachstehendem Ergebnis durchgeführt:

 

 

 

Die Erstgewichtung erfolgte, indem Probanden mit unterschiedlichem Fokus, wie Verantwortlichkeit für Budget, Haustechnik, Informationstechnologie etc., die Oberziele und Ziele bewerteten und aus diesen Bewertungsergebnissen ein Mittelwert gebildet wurde.

Danach legte jeder Proband seine Motivation für die Gewichtung dar, wobei auch Abhängigkeiten und Mindesterfordernisse erörtert wurden. Insbesondere wurde zwischen bauherrn- und planerseitigen sowie auftragnehmerseitigen Kriterien differenziert, ohne dass KO-Kriterien definiert wurden, da es nicht um die Auswahl von Bewertungsalternativen geht.

Nach Diskussion der Abhängigkeiten und Mindestanforderungen wurde die Zweitgewichtung in einer weiteren Bewertungsrunde erstellt. Ohne ausreichend qualifizierte Planung ist die Umsetzung der übrigen fünf Hauptziele nicht möglich. Ohne Erfüllung der Funktionalität und Interoperabilität können Wirtschaftlichkeit und Betrieb nicht gewährleistet werden. Sicherheit ist eine zwingende Anforderung für den Betrieb der Gebäudeautomation.

Wirtschaftlichkeit hat die höchste Bedeutung, diese wird die Gewichtung der qualifizierten Planung, der Interoperabilität und dadurch mehr Konkurrenz und Wirtschaftlichkeit i.e.S. ausgedrückt.

 

Funktionalität

Bei der Funktionalität kann das Gesamtsystem zGA betrachtet werden. Sinnvollerweise wird jedoch zwischen Feld-, Automations- und Managementebene differenziert.

Ein wichtiges Ziel ist es, GA-Systeme und Automationsstationen (AS) mehrerer Liegenschaften an einer gemeinsamen Management- und Bedieneinheit (MBE) über die Office-Arbeitsplätze visualisieren und steuern zu können. Das erfordert WEB-fähige Lösungen auf der MBE-Ebene und einheitliche Vorgaben für die Bilderstellung und Dynamisierung für die Umsetzung der GA in den Liegenschaften.

Ein weiterer wichtiger Aspekt sind die Funktionalitätsvorgaben, um den notwendigen Komfort und die geforderten Energieeinsparungen umsetzen zu können.

Als nachteilig erwies sich, dass nach Upgrade der im Rahmen der zGA genutzten MBE die Bilder der Visualisierung nicht übernommen werden konnten und daher neu zu erstellen und zu dynamisieren waren. Diesem Dienstleistungsaspekt ist ca. ein Drittel der Umstellungskosten zuzuordnen.

Durch einheitliche Vorgaben und qualifizierte Experten kann die Bilderstellung zum Teil durch eigenes Personal wahrgenommen werden, wodurch teure Firmenleistungen vermieden werden können. Bei Neubeschaffung der MBE werden höhere Funktionalitäts- und Qualitätsanforderungen gestellt und die Übernahme der Anlagenbilder, Dynamisierung und Benutzeradressierung gefordert.

Für die Automationsstationen (AS) sind über die bisherigen Realisierungen hinausgehende Anforderungen an Geräte und die Umsetzung (gemäß Lastenheft) vorzugeben. Dabei ist zwischen proprietären und interoperablen Controllern zu differenzieren.

Der Zusammenhang zwischen der GA-FL und der Umsetzung der Anforderungen in der AS sowie das Auslesen bzw. der Austausch der umgesetzten Funktionalitäten von der AS über den EDE-File (Engineering Data Exchange) zur MBE sind essenziell für eine konsistente Gesamtlösung, wobei jedoch die EDE-Datei nur eine freiwillige Festlegung der BACnet Interest Group Europe aus dem ersten Berliner Multivendor-Projekt ist. Sie ist nicht genormt und wird aktuell überarbeitet.

Ergebnisse:

- Mängel in der GA-Funktionalität konnten behoben werden,

- Erkenntnisse über die Vereinheitlichung der Funktionalität konnten gewonnen werden.

Probleme:

- fehlerhafte Konnektivität der Ethernet-Schnittstelle moduNet 292,

- AS, die nicht automationsunterstützt, sondern nur manuell in die MBE eingebunden werden können (BACnet BBMD-Routing),

- fehlender Zugang zu den Zeitprogrammen in der MBE,

- fehlende Trendobjekte,

- Duplikate von übertragenen Werten in der Datenbank,

- SMS-Alarmierungen mit Umlauten im Text wurden mit der Standardkonfiguration nicht übermittelt,

- Regelventile, deren per MBE gewählte Betriebsart nicht mehr auf Automatik zurückgestellt werden konnte (fehlende Hilfsvariable und falsche Skalenbeschränkung) etc.

 

Wirtschaftlichkeit

Die Wirtschaftlichkeit ist abhängig von diesbezüglichen Planungsvorgaben. Die Vorgabe zweckadäquater Funktionalitäten, interoperabler (Konkurrenz) und handhabbarer Lösungen (Betrieb) sowie die Übernahme von vorhandenen Bildern bei zu erneuernden Anlagen sind bewertungsrelevant.

Ergebnisse:

- Hardwarekosten wurden reduziert, da anstelle der redundanten „Haustechnik-PC“ WEB-Lösungen über die Standardarbeitsplätze im HBN genutzt werden,

- Softwarekosten wurden reduziert, da Software für redundante Arbeitsplätze wegfällt (Betriebssystem, Office-Software, Virenschutz etc.) und da die Kosten der MBE-Software (einmalig statt je Standort) und die Kosten pro Datenpunkt (65.000er- statt 2.000er-Lizenz) optimiert werden konnten,

- Betriebskosten werden reduziert, da die Wartung der redundanten Haustechnikarbeitsplätze wegfällt und die Funktionalität über die Standard-Büroarbeitsplätze wahrgenommen wird,

- Beschaffungskosten für neue GA-Komponenten wurden reduziert, da Produkte unterschiedlicher Hersteller eingebunden werden können und durch mehr Konkurrenz auf Dauer bessere Preise erzielt werden können.

Probleme:

- Die Kosten für die Bedarfsermittlung und Planung sind gestiegen,

- die Kosten für das Engineering und die Kommunikation in der Projektabwicklung sind gestiegen, wobei eine neutrale Ausschreibung auf Basis der GA-Weltnorm und der LB-HT dem entgegenwirkt,

- die erwarteten Kosteneinsparungen durch einheitliche Bilder und Dynamisierungen konnten auch aufgrund der unzureichenden Funktionalität der MBE noch nicht realisiert werden,

- zusätzliche Kosten sind für die Aus- und Weiterbildung der eigenen Mitarbeiter angefallen, die jedoch für GA grundsätzlich anfallen.

Ein für acht Standorte angestellter Wirtschaftlichkeitsvergleich zwischen der bisherigen ausschließlich proprietären Variante und der umgesetzten zGA-Lösung mit proprietären und interoperablen Komponenten ergab ein Einsparungspotenzial von mehr als der Hälfte, wobei sich diese Einsparung bei Folgeprojekten mit richtig ausgeschriebener BACnet-GA potenzieren wird.

Ob und inwieweit Einsparungen bereits beim Energieverbrauch lukriert werden können, lässt sich aufgrund der kurzen Dauer des Projekts noch nicht evaluieren. Der Komfort ist im Wesentlichen unverändert.

 

Interoperabilität

Interoperabilität im Sinne dieses Projekts bedeutet, dass Automationseinrichtungen (Controller) unterschiedlicher Hersteller genutzt werden können. Im konkreten Projekt werden proprietäre und interoperable Geräte eines Herstellers und interoperable Devices unterschiedlicher Hersteller in verschiedenen Liegenschaften über das BACnet-Kommunikationsprotokoll und eine zentrale MBE visualisiert, gesteuert (also bedient) und gemanagt.

Ergebnisse:

- Reduktion der Abhängigkeit von einem (einzigen) Hersteller,

- Skalierbarkeit bzw. optimierte Ausbau- und Erweiterungsmöglichkeiten durch Einsatz von BACnet sowie auch durch einheitliche Vorgaben im Lastenheft,

- Investitionssicherheit für den Bauherrn,

- Zukunftssicherheit, auch weil sich zusätzlich zur „klassischen“ GA die Beleuchtungs-, Gefahrenmelde-, Zutrittskontroll- und Videotechnik sowie die allgemeine Stromversorgung zunehmend am BACnet-Protokoll orientieren,

- Verbesserung der Wirtschaftlichkeit und im Betrieb.

Probleme:

- Lastenhefte werden nicht in Pflichtenhefte transformiert, sondern es werden ein Engineering der Anlagen durchgeführt und Umsetzungen anhand von Softwaretools präsentiert,

- interoperable Vorgaben des Lastenhefts (welche Objekte, Properties und Dienste zu nützen sind oder nicht) werden nur teilweise umgesetzt, da Engineering-Tools anzupassen sind,

- die Zuordnung der umgesetzten BACnet-Objekte zur vorgegebenen GA-FL ist teilweise aufwendig, da die Engineering-Tools über keine ausreichenden Schnittstellen verfügen,

- die verwendeten Begriffe entsprechen nicht der Norm, und die neutralen Planungswerkzeuge werden teilweise von der Industrie konterkariert. Sie sind in vielen Fällen praxiserprobt, jedoch versuchen sich Hersteller herauszuwinden. Natürlich bedarf die vor 25 Jahren entwickelte GA-FL erheblicher Optimierungen und Anwendungsvorgaben, um eine 1:1-Beziehung zwischen Planung und Umsetzungen zu gewährleisten,

- Wissen und Erfahrung der Beteiligten sind teilweise für die Umsetzung einer BACnet-Multi Vendor-Anlage unzureichend. Das Wissen über proprietäre Anlagen reicht nicht aus, die Abgrenzung zwischen erforderlicher BACnet-Ausbildung und -Erfahrung und wissenschaftlicher Forschung wird durch die Beteiligten unterschiedlich bewertet.

Zertifizierte BACnet-Devices sind notwendig, aber nicht hinreichend zur Gewährleistung von Interoperabilität, „Plug and Play“-Lösungen gibt es bei BACnet nicht, Multi Vendor-Lösungen erfordern disziplinenübergreifendes Know-how auf Auftraggeber- und v.a. Auftragnehmerseite. Nur wenn Basiswissen und Erfahrung über BACnet verfügbar sind, mit der GA-FL und dem Lastenheft projektspezifische Anforderungen definiert und im Engineering-Prozess auch konsequent realisiert werden, können die wirtschaftlichen Vorteile von BACnet und der Gebäudeautomation genutzt werden.

Aufgrund der geringen Anzahl von Fachleuten, die übergreifende Fachkenntnisse im HKLSE-, MSR-, BACnet- und IKT-Bereich besitzen, ist die Aus- und Weiterbildung für BACnet ein Schlüssel, um den Mehrwert der Interoperabilität auch nutzen zu können.

Mittelfristig werden sich offene produktneutrale Lösungen durchsetzen und auch die Beteiligten erkennen, dass die Werkzeuge und Prozesse zur Umsetzung der Gebäudeautomation, die aus dem vorigen Jahrhundert stammen, zu verbessern sind.

 

Sicherheit

Zu Beginn des Projekts wurden eine Risikobeurteilung nach ÖNORM ISO 31000 mit externer Unterstützung durchgeführt und davon abgeleitet Sicherheitsmaßnahmen für einzelne Systemkomponenten (Feldsysteme, Zweidrahtleitungen, Automationseinrichtungen, LAN-Anbindungen, Management- und Bedieneinrichtungen etc.) definiert.

 

 

Ausgehend von der Risikobeurteilung lassen sich nachstehende Maßnahmen ableiten:

- physische Sicherheit,

- Netzwerksicherheit,

- Applikationssicherheit.

Diese Dreiteilung wurde unabhängig von den in der Norm definierten Sicherheitsfunktionen (Addendum g), die von den Herstellern nie umgesetzt wurden, gewählt. Der erste Aspekt ist maßgeblich von örtlichen Rahmenbedingungen abhängig und jedenfalls losgelöst von BACnet zu gewährleisten. Auch die Netzwerksicherheit sollte allein aus Wirtschaftlichkeitsüberlegungen losgelöst von den einzelnen IT-Services und daher auch von BACnet realisiert werden. Die Applikationssicherheit bezieht sich überwiegend auf Sicherheitsanforderungen an die BACnet Software (MBE) - die nach ÖNORM EN ISO 16484-2 und -3 spezifiziert und bei der Auswahl der Systeme evaluiert werden muss.

Physische Sicherheit hängt von den in der jeweiligen Liegenschaft bereits umgesetzten Sicherheitsmaßnahmen wie z.B. personelle Bewachung, technische Sicherheitsmaßnahmen durch Zutrittskontrollsysteme, Einbruchmeldeanlagen etc. und der Umsetzung der Sicherheitserfordernisse anhand des „Zwiebelschalenprinzips“ (Zutritt zur Liegenschaft, zum Objekt, zum Heizraum, zum Verteiler- oder Schaltschrank etc.) ab.

Netzwerksicherheit ist im Zusammenhang mit GA und BACnet ein Thema, das bislang sehr stiefmütterlich behandelt wurde. Auch wenn bereits im Jahr 2010 mit dem „Addendum g“ das Thema Sicherheit im BACnet-Standard adressiert wurde, sind im Jahr 2015 keine Devices bekannt, für die diese Funktionalität realisiert wurde. Da sich die Anforderungen für die einzelnen IT-Services überschneiden und weitgehend Standards, Methoden und Werkzeuge, die im IKT-Bereich üblich sind, verwendet werden, sind Synergien nutzbar.

Während Netzwerksicherheit im LAN-Bereich verfügbar ist, bestehen insbesondere bei den „billigen“ Feld-Netzwerken der BACnet-Netzwerkoptionen erhebliche Nachholbedarfe.

Ergebnisse:

- Durchführung der Risikobeurteilung und Definition von Sicherheitsmaßnahmen,

- Gewährleistung zweckmäßiger physikalischer Sicherheitsmaßnahmen (vierte Zwiebelschale im Hochsicherheitsbereich),

- Netzwerksicherheit durch Trennung in virtuelle Netze (VLAN),

- verschlüsselte und kabelgebundene Datenübertragung (AES 256),

- Authentifizierung und Autorisierung im Netzwerk (IEEE 802.1.x etc.),

- Nutzung Netzwerkmanagementsystem und Schlüsseltausch,

- Application-Firewall (Layer 7 etc.).

Probleme:

- Probleme in der Betreibbarkeit der Systeme durch die Nutzung der aufwendigeren Layer 3- statt Layer 2-Funktionalitäten,

- fehlende Sicherheitspatches für das Betriebssystem, die Entwicklungssprache und den zugrunde liegenden Virenschutz für die MBE-Software,

- mangelnde sichere Softwareentwicklung für die MBE-Software (ÖNORM A 7700, OWASP Application Security Verification Standard (ASVS)),

- MBE läuft nicht als Service am Server und erfordert eine automatische Anmeldung des Anwenders,

- unzureichend gesicherte Fernwartungszugänge,

- keine Garantie, dass nicht dokumentierte Funktionalitäten bzw. Standard-Accounts nicht vorliegen,

- fehlende unabhängige Überprüfung proprietärer Protokolle und sicherheitsrelevanter Algorithmen durch einen unabhängigen Dritten im Sourcecode,

- fehlender dokumentierter Patch Management-Prozess mit zeitnaher, proaktiver Einbindung der Kunden (Information bereits bei Bekanntwerden einer Schwachstelle) etc.

Die Auflistung der Mängel in der Applikationssicherheit ist nicht vollständig. Wenn jedoch die Java-Patches von fast einem Jahr nicht eingespielt werden können, weil die MBE dann nicht lauffähig ist und das mit den Worten „Das ist halt so“ kommentiert wird, weiß man, dass das Thema Sicherheit bei vielen Herstellern in der Branche noch nicht angekommen ist.

Jeder, der aktuell eine MBE ausschreibt, sollte daher zwingend fordern, dass Sicherheitspatches des zugrunde liegenden Betriebssystems, der Datenbank, der Anwendungsprogramme und des Anwendungs-Programmiertools, der Entwicklungssprache, des Malwareschutzes und von sonstigen Sicherheitslücken der MBE innerhalb angemessener Frist bereitzustellen sind.

Wenn der Hersteller Ihnen zu diesem Thema keine Auskunft geben kann oder feststellt, dass es diese Probleme nicht gebe, sollten Sie mit Sicherheit einen anderen Lieferanten/Partner suchen.

Fehlende Sicherheit ist kein Thema „von anderen“, das uns nicht berührt. Es ist vielmehr eine sehr reale Herausforderung im GA-Bereich, die uns in der nächsten Zeit erheblich beschäftigen wird.

 

Betrieb

Vorteile der Gebäudeautomation, wie die Langlebigkeit der Systeme, die teilweise seit 25 Jahren im Einsatz sind, führen zu besonderen Anforderungen an den Betrieb. Auch wenn die GA nicht die kurzen Entwicklungszyklen der IT aufweist, sind in gewissen Zeitabständen Komponenten und Know-hows eines Herstellers nicht mehr verfügbar, bzw. steigen die Kosten für die Inanspruchnahme der Leistung exponentiell.

Ein weiterer wichtiger Aspekt des Betriebs sind einheitliche Vorgaben für die Bilderstellung und Bilddynamisierung sowie deren Übernahme bei neuer Firmware in der AS und neuen Versionen in der MBE.

Ergebnisse:

- Die redundante Wartung der „Haustechnik-PC“ entfällt, da die Basisinfrastruktur über einen HBN-Standardclone bereitgestellt werden kann,

- fachlich kompetentes Personal kann flexibler eingesetzt werden, da ein Zugriff von allen Arbeitsplätzen im Heeresbaunetz möglich ist,

- die liegenschaftsübergreifende Alarmweiterleitung konnte eingerichtet werden,

- ein übergeordnetes Controlling durch die Möglichkeit zentraler Abfragen, Auswertungen etc. ist möglich,

- ein zentrales Management durch Analysen und Steuerung wird möglich.

Probleme:

- Der Aufwand für den Betrieb der Netzwerksicherheit für größere Anlagen ist problematisch,

- die Benutzerfreundlichkeit im Bereich der MBE lässt zu wünschen übrig,

- in der MBE sind gewisse Funktionen (Zeichensatz, zentrales Backup und Restore etc.) aufgrund des Faktums, dass nur BACnet Revision 1.09 unterstützt wird, nicht verfügbar,

- die Kombination aus proprietären und interoperablen Funktionalitäten führt zu einem Mehraufwand,

- die MBE erfordert lokale Administrationsrechte,

- die MBE läuft nicht als Dienst und erfordert lokale Datenablagen,

- eine lokale Benutzerverwaltung ist erforderlich, und die Active Directory-Einbindung ist nur eingeschränkt umgesetzt,

- funktionale Anforderungen sind nicht optimal gelöst etc.

Die Umsetzung der Netzwerksicherheit im Bereich von Zweidrahtleitungen analog der LAN-Infra­struktur erscheint eine bewältigbare Herausforderung. Verbesserungen sind in Bezug auf den laufenden Betrieb erforderlich (Nutzung von Layer 2- statt Layer 3-Werkzeugen).

Die Applikationssicherheit, die in der Softwareindustrie ein Kernthema ist, wird auch den Bereich der Gebäudeautomation erreichen. Entwicklungen wie SmartHome und der unverzichtbare IT-Einsatz werden sich mit Sicherheit auch auf diese Branche auswirken.

 

Zusammenfassung

Gute Ergebnisse und Wirkungen der Gebäudeautomation sind bei interoperablen Projekten, wo heterogene Teilsysteme unterschiedlicher Hersteller zu integrieren sind, abhängig von klaren, eindeutigen Schnittstellen, Aufgabenzuordnungen und Verantwortlichkeiten für alle Beteiligten im Projekt.

Neben einer detaillierten Planung sind die vertraglichen Regelungen mit den Auftragnehmern und die Festlegung, wer welche Leistungen und Systemintegrationsaufgaben wo erbringt, essenziell.

Auch ist die Frage nach dem Detaillierungsgrad der Planung herausfordernd, um einerseits die Einbindung von Multi Vendor-Anlagen sicherzustellen und andererseits die unterschiedlichen Funktionen der Produkte der einzelnen Anbieter bestmöglich zu nutzen sowie den Aufwand für das Engineering der Systeme zu optimieren.

Dabei sind die unterschiedlichen Philosophien der Hersteller (veraltete Leittechnik, SCADA, GA-MBE etc.) und die Nutzung des notwendigen Freiraumes, den die Reihe der Weltnorm ISO 16484-5 bietet, zu berücksichtigen.

Im Projekt „zentrale Gebäudeautomation“ (zGA) war vorgegeben, dass die Planung und Sicherheit gemeinsam konzipiert und umgesetzt werden und dass durch den Auftragnehmer ein Ausbildungspaket angeboten wird, um zukünftig Betrieb und Engineering-Dienstleistung zur Bilderstellung und Dynamisierung im eigenen Bereich sicherstellen zu können.

Eine Herausforderung war die Trennung zwischen Vorgaben für produktneutrale Lösungen (Planung etc.) und der Zulässigkeit von proprietären Werkzeugen wie z.B. dem Engineering Tool und den Werkzeugen zur Bilderstellung und -dynamisierung.

Dass die Form der Zusammenarbeit auf Basis eines „Letter of Intent“ und eines Auftrags Ergebnisse, aber auch offene Probleme mit sich gebracht hat, zeigt das Diagramm mit der Bewertung der sechs Zieldimensionen des Pilotprojekts „zentrale Gebäudeautomation“ (zGA):

 

 

Aus dem Spinnendiagramm ist der Grad der qualitativen Zielerfüllung (nicht quantitativ) für die sechs Zieldimensionen im Zusammenwirken zwischen Auftraggeber (inkl. Planer) und Auftragnehmer ersichtlich.

Eine Kernaussage lässt sich aus dem Projekt zGA ableiten:

Den folgenden Absatz mit Rahmen und grauer Hinterlegung versehen!

Wenn Auftraggeber und Planer keine detaillierten Vorgaben der Gebäudeautomation (Planung inkl. BACnet-Objekte und BIBBs) erstellen und die erbrachten Leistungen des Auftragnehmers auf Übereinstimmung mit den Vorgaben (GA-FL und Lastenheft) nicht im Detail überprüfen, kann nicht davon ausgegangen werden, dass interoperable Systeme erstellt werden. Eine Planung, die anwendungsorientierte Interoperabilität dokumentiert, und die Überprüfung, ob diese in der Realisierung 1:1 umgesetzt wurde, sind unverzichtbar für die Integration von Komponenten unterschiedlicher Hersteller auf Basis von BACnet.

Einige der offenen Probleme sind aber sowohl durch Auftraggeber als auch Auftragnehmer schwer zu lösen. Hier wären übergeordnete Aktivitäten zweckmäßig.

Normungsgremien ASHRAE, ISO, EN, ÖNORM:

- Die Handlungsspielräume in den Standards und der Übergang zwischen Teil 3 und Teil 5 der ISO 16484 sollten konkretisiert werden. Eine verpflichtende Erweiterung der GA-FL um die BACnet-spezifischen Elemente (DP-Name, Zuordnung von DP zu Funktionen, BIBBs etc.) und die Normierung des Datenaustauschformats zwischen Planung und Realisierung (ev. in Analogie zu Engineering Data Exchange) sollten normativ geregelt werden.

- Die zeitgemäßen Standards im Bereich der Informationstechnologie sollten in den BACnet-Standard übernommen und durch die Hersteller der Produkte umgesetzt werden. Mehr Konvergenz zwischen der Gebäudeautomation und der Informations- und Kommunikationstechnologie sollte geschaffen werden.

- Die Netzwerksicherheit und die diesbezüglichen in der IT-Branche etablierten Standards sind losgelöst von BACnet zu realisieren, da Sicherheitsbedrohungen die größten Herausforderungen der Zukunft darstellen. Klare Vorgaben an die physikalische Sicherheit, Netzwerksicherheit und insbesondere Applikationssicherheit sind unverzichtbar.

- Nicht nur die neuen BACnet-Addendas, sondern auch die vorlaufenden Strategien, Roadmaps und Zukunftsüberlegungen sollten einer breiten Öffentlichkeit zugänglich gemacht werden. Aktuelle Entwicklungen wie Energieeffizienz, Building Information Modeling etc. mit hohem Marktpotenzial sollten durch die BIG-EU und ASHRAE aktiv in ihre mittelfristigen Pläne einbezogen werden. Wenn ein Vertreter der BIG-EU anlässlich der 20-Jahr-Feier in BERLIN über „BACnet 2“ referiert und entsprechende Dokumente ankündigt, diese aber trotz Anforderung viele Monate danach immer noch nicht zur Verfügung gestellt wurden, besteht Optimierungsbedarf im Bereich der Informationspolitik. GA und IT sind keine Widersprüche, sondern beide sind für eine ganzheitliche Betrachtung von Gebäudeautomation zwingend erforderlich.

Standesvertretungen VDI, BIG-EU, BMWWF:

- Auf der Homepage der BIG-EU sollten zertifizierte Geräte nach verschiedenen Kriterien, wie z.B. Testplan, Gültigkeitsdauer des Zertifikats, Devicetyp, gefiltert werden können.

- Die Vorteile der Interoperabilität zur Steigerung der Wirtschaftlichkeit der Gebäudeautomation im Hinblick auf Energieeffizienz in der Nutzungsphase sollten der Politik und einer breiten Öffentlichkeit stärker nahegebracht werden. Dazu sind qualifizierte Veröffentlichungen in Fachmagazinen und Vorträge bei einschlägigen Veranstaltungen erforderlich.

- Eine qualifizierte Ausbildung der Bauherren, Planer und ausführenden Firmen ist der Schlüssel, der entscheidet, ob BACnet ein Thema weniger Spezialisten bleibt oder in der Branche ankommt. Aufgrund der Komplexität des Themas (Theorie und Praxis zu HLKSE, MSR, IKT, BACnet etc.) sollte eine mehrstufige Ausbildung über Ziele und Wirkungen mit Basis- und Detailinformationen zu BACnet in diesbezüglichen Workshops vermittelt werden.

- Normen in englischer Sprache, wobei der BACnet-Kommunikationsstandard mehr als 1.000 Seiten und die Prüfnorm ca. 500 Seiten umfasst, sind nicht ausreichend. Auch wenn sich die Norm primär an Softwareentwickler richtet, sind auch Bauherren und Planer davon betroffen. Eine deutsche Übersetzung würde analog den Franzosen und Italienern zur Verbreitung des Standards beitragen. Das Buch „BACnet Gebäudeautomation 1.12“ von Hans Kranz gibt einen guten Überblick und ist leicht lesbar, ist aber mit seinen 568 Seiten auch keine Einführungslektüre. Leicht verständliche Broschüren und Einführungsvorträge, die die Vorteile von BACnet erläutern, wären verstärkt bereitzustellen. Ansätze dazu findet man unter http://www.big-eu.org/service/literatur-zum-standard/.

- Zweitägige Ausbildungen zu BACnet, wo fast 1.000 Seiten PowerPoint-Folien durchgepeitscht werden, Detailprobleme mit Netzwerkanalysewerkzeugen analysiert werden und die sich an eine heterogene Zielgruppe wie Entwickler und Produktmanager sowie Mitarbeiter aus den Bereichen Planung, Ausführung und Betrieb der Gebäudeautomation richten, sind wohl als suboptimal zu bezeichnen.

- Die von der BACnet Interest Group Europe (BIG-EU) angekündigte Offensive zur Aus- und Weiterbildung der Planer sollte ehestmöglich umgesetzt werden. Sie wurde als BACnet Academy (in Englisch, Italienisch und Französisch, aber leider nicht in Deutsch) gestartet.

- Die standardisierte Leistungsbeschreibung Haustechnik (LB-HT) sollte auf die Anforderungen für die Umsetzung von Multi Vendor-Anlagen mit BACnet adaptiert werden.

Resümee

Standards und Interoperabilität sind die Chance, um die Abhängigkeiten von einem Hersteller zu reduzieren, die technologischen Entwicklungen besser zu nützen, die lebenszyklischen Kosten der Gebäudeautomation zu verringern und Sicherheitsrisiken zu reduzieren.

Experten im Facility Management gehen davon aus, dass 80 bis 90% der Kosten über den Lebenszyklus der Immobilie in der Nutzungsphase anfallen. Ein wichtiger Kostenblock sind Energieausgaben, die auch im Fokus der Gebäudeautomation stehen. Durch optimierte Prozesse wie Building Information Modeling (BIM) können auch neue Möglichkeiten zur Effizienzsteigerung im Bereich des Energieverbrauchs in Kombination mit der Gebäudeautomation erschlossen werden.

Je mehr Standards und normierte Prozesse im Bereich der GA eingesetzt werden, desto leichter wird es möglich sein, die Effizienzpotenziale in der Nutzungsphase (Tausch von Komponenten, Energieeinsparungen, Komfortverbesserungen etc.) auch faktisch zu nutzen.

Die Zahl der Vendor-IDs, die Anzahl der BACnet-gelisteten Produkte und die Preise von wenigen 100 USD für Controller zeigen, dass am Markt ein großes Angebot an BACnet-Devices existiert. Wichtiger ist jedoch das notwendige Know-how, daraus funktionierende Anlagen zu bauen.

Die wirtschaftlichen Vorteile des Wettbewerbs können nur genützt werden, wenn durch die Planung im Projekt die liegenschaftsspezifischen GA- und BACnet-Anforderungen ausreichend definiert (Adressierungen GA-Funktionen, Dienste und Netzwerke) und deren Umsetzung durch den Auftragnehmer kompetent kontrolliert werden. Ansonsten ist Missbrauch Tür und Tor geöffnet.

Nur wenn die Gebäudeautomation ganzheitlich betrachtet wird und die Aspekte der Planung, der Funktionalität, der Wirtschaftlichkeit, der Interoperabilität, der Sicherheit und des Betriebs den liegenschafts- und organisationsspezifischen Anforderungen entsprechen, kann GA mit BACnet zu effizienten und effektiven Prozessen in der Organisation beitragen.

Der zentrale Schlüssel ist jedoch, dass die Vorteile von BACnet einer breiten Community zugänglich gemacht werden und nicht, wie derzeit, ein Wissen weniger Spezialisten bleibt.

 


 

ANMERKUNGEN:

1) Vgl. Barry Buzan: New Patterns of Global Security in the Twenty-first Century. In: International Affairs 1991, S.432f.

2) Vgl. Rupert Fritzenwallner, Reinhard Hammerschmid: Forschungsprojekt „Corporate Security Management“ - ein Statusbericht. In: Österreichische Militärische Zeitschrift 3/2013, S.292ff.

3) Vgl. Rupert Fritzenwallner, Uli Barth: Risikomanagement - eine ganzheitliche Herausforderung? In: Technische Sicherheit VDI Verlag, 2012, S.19ff.

4) Vgl. Jaspreet Kaur, Michael Meier, Sebastian Szlòsarczyk, Steffen Wendzel: A Cost-efficient Building Automation Security Testbed for Educational Purposes, 2014, S.1ff.

5) Vgl. Thomas Bednar, Josef Eberhardsteiner, Rupert Fritzenwallner, Maximilian Neusser, Helmut Weinhardt: Zur Energieträgerverbrauchsprognose großer heterogener Gebäudebestände. 2015.

6) „Optional“ bezieht sich auf die erforderliche Funktion im realen Projekt - nicht auf die Produktentwicklung.

7) Vgl. Hans R. Kranz: BACnet Gebäudeautomation 1.12. Grundlagen in deutscher Sprache. 2013, S.139.

8) Vgl. TRIC DB BACnet der Fa. Mervisoft und SHN - technical solutions, Suiten BAControl und BAProject der Fa. WSCAD electronic GmbH etc.

9) Vgl. Bundesministerium für Wirtschaft, Familie und Jugend (BMWFJ) (2013): Standardisierte Leistungsbeschreibung Haustechnik, Version 10.

10) Die EDE-Datei ist in der ÖNORM EN ISO 16484-5 nicht geregelt, sondern wurde durch die BIG-EU entwickelt.

11) Vgl. Christof Zangemeister: Nutzwertanalyse in der Systemtechnik - Eine Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen. 1976.