Objektvorgaben in der BACnet-Planung: Was man vorschreiben muss, und warum

Im ersten Teil dieser Serie haben wir geklärt, warum BACnet-Planung eine eigenständige Disziplin ist. Jetzt wird es konkret: Welche Objekttypen, Properties und Dienste muss der Planer in der Ausschreibung vorschreiben, damit eine Gebäudeautomation tatsächlich interoperabel, wartbar und herstellerunabhängig wird?

Dieser Artikel richtet sich an HLK-Planer und Generalplaner, die BACnet-Vorgaben für ihre Projekte formulieren müssen, aber auch an Bauherren und GU/TU, die verstehen wollen, was in einem professionellen GA-Leistungsverzeichnis stehen sollte. Die technische Mechanik der einzelnen Objekttypen behandelt unsere Serie «BACnet Objekte verstehen», hier geht es um die Planungsperspektive: Was vorschreiben, warum, und was passiert, wenn man es weglässt.

Objektvorgaben sind kein optionaler Luxus für grosse Projekte. Auch bei kleineren Anlagen entscheidet die Qualität der Vorgaben darüber, ob der Betreiber später effizient arbeiten kann.

Objektvorgaben bilden die Brücke zwischen dem, was der BACnet-Standard ermöglicht, und dem, was ein konkretes Bauprojekt braucht. Sie übersetzen abstrakte Normenanforderungen in praxistaugliche, prüfbare Ausschreibungstexte. Wer diesen Schritt überspringt, überlässt die Qualität seiner Gebäudeautomation dem Zufall.

Warum Objektvorgaben so wichtig sind

Ein BACnet-Gerät kann Dutzende verschiedener Objekttypen unterstützen: Analog Input, Binary Output, Trend Log, Schedule, Event Enrollment, Device und viele mehr. Jeder Objekttyp hat obligatorische und optionale Properties. Und jedes Gerät kann unterschiedliche Dienste (Services) unterstützen, zum Beispiel ReadProperty, WriteProperty, SubscribeCOV oder ConfirmedEventNotification.

Die BACnet-Norm (ISO 16484-5) definiert, was technisch möglich ist. Sie schreibt aber nicht vor, was in einem konkreten Projekt gefordert werden muss. Das ist die Aufgabe des Planers.

Ohne Objektvorgaben entscheidet der Systemintegrator, welche Objekttypen er anlegt, welche Properties er befüllt und welche Dienste er aktiviert. Er tut das nach seinen eigenen Standards, die nicht zwingend den Bedürfnissen des Betreibers entsprechen. Das Ergebnis: Geräte, die formal BACnet sprechen, aber funktional nicht das liefern, was der Betrieb braucht.

Anforderungsprofile: AS-CH und MBE-CH

Die KBOB-Empfehlung «BACnet Anwendung» definiert schweizspezifische Anforderungsprofile, die über die internationalen BACnet-Geräteprofile hinausgehen:

AS-CH (Automationsstation Schweiz)

Dieses Profil beschreibt die Mindestanforderungen an eine Automationsstation (Controller, DDC). Es legt fest, welche Objekttypen die Station unterstützen muss (z. B. Analog Input, Analog Output, Binary Input, Binary Output, Trend Log, Schedule, Calendar, Event Enrollment), welche Properties obligatorisch sind und welche BIBBs (BACnet Interoperability Building Blocks) implementiert sein müssen.

Konkret fordert AS-CH unter anderem die Unterstützung von Intrinsic Reporting, also die Fähigkeit, Alarme direkt auf dem Gerät zu erzeugen, ohne dass ein Leitsystem die Alarmlogik übernehmen muss. Das ist entscheidend für die Betriebssicherheit: Fällt das Leitsystem aus, meldet das Gerät trotzdem weiter.

MBE-CH (Management- und Bedieneinrichtung Schweiz)

Das MBE-CH-Profil definiert die Anforderungen an das Leitsystem (Management-Station, Visualisierung). Es stellt sicher, dass das Leitsystem alle relevanten Dienste beherrscht: Lesen und Schreiben von Properties, Empfangen von Alarmen (ConfirmedEventNotification), Abfragen von Trends (ReadRange) und die Verwaltung von Zeitprogrammen.

Warum diese Profile in die Ausschreibung gehören

Wer in der Ausschreibung nur «BACnet/IP» fordert, bekommt ein Gerät mit irgendeinem BACnet-Profil. Das kann ein B-ASC sein (Advanced Smart Actuator, sehr eingeschränkt) oder ein B-BC (Building Controller, umfangreich). Die KBOB-Profile stellen sicher, dass der Mindestfunktionsumfang dem entspricht, was ein Schweizer Bauprojekt typischerweise braucht.

Die wichtigsten Objekttyp-Vorgaben im Überblick

Nicht jeder Objekttyp muss in jedem Projekt vorgeschrieben werden. Die folgende Übersicht zeigt die Objekttypen, die in den meisten Projekten relevant sind, und was der Planer dazu festlegen sollte:

Analoge und binäre Ein-/Ausgänge (AI, AO, BI, BO)

Diese Objekttypen bilden die physischen Datenpunkte ab: Temperaturfühler, Drucksensoren, Klappenstellungen, Ventilpositionen, Pumpen- und Lüfterstatus. Der Planer sollte festlegen, welche Properties neben Present_Value zwingend geliefert werden müssen, typischerweise Object_Name (nach definierter Namenskonvention), Description (Klartext), Units (Einheit, z. B. degrees-Celsius), Out_Of_Service, Status_Flags und Reliability.

Multi-State Objekte (MSI, MSO, MSV)

Für Betriebsmodi (Heizen/Kühlen/Standby), Stufenschaltungen und Zustandsmeldungen. Wichtig: Der Planer muss die State_Text-Liste vorschreiben (welche Zustände gibt es, in welcher Reihenfolge), damit alle Geräte dieselbe Terminologie verwenden.

Trend Log und Trend Log Multiple

Ohne Trend-Log-Vorgaben zeichnet der Integrator entweder gar nicht auf oder nach eigenem Gutdünken. Der Planer sollte vorschreiben, welche Datenpunkte geloggt werden müssen, ob Polling oder COV (Change of Value), welches Aufzeichnungsintervall gilt und wie gross der Ringpuffer sein muss (Buffer_Size). Die Details dieser Objekttypen beschreibt Teil 4 unserer Serie «BACnet Objekte verstehen».

Schedule und Calendar

Zeitprogramme müssen direkt im Gerät laufen, nicht nur auf dem Leitsystem. Der Planer sollte vorschreiben, wie viele Schedule- und Calendar-Objekte pro Station mindestens angelegt werden müssen, welche Wochenprogramme und Ausnahmetage zu unterstützen sind und ob die Schedules per BACnet-Dienst (WriteProperty) vom Leitsystem änderbar sein müssen.

Event Enrollment und Notification Class

Die Alarmkonfiguration. Der Planer muss festlegen, welche Datenpunkte alarmiert werden (Grenzwertüberschreitungen, Zustandswechsel, Fault-Zustände), welche Notification Classes verwendet werden (Prioritätsklassen) und welche Empfänger in der Recipient_List stehen. Teil 5 der Serie «BACnet Objekte verstehen» behandelt die technische Mechanik im Detail.

Device Object

Jedes BACnet-Gerät hat genau ein Device Object, das seine Identität definiert. Der Planer muss den Bereich für Object_Identifier (Device-ID) festlegen, typischerweise ein Nummernbereich pro Gebäude, Geschoss oder Gewerk. Ohne diese Vorgabe entstehen ID-Kollisionen, sobald Geräte verschiedener Hersteller im selben Netzwerk zusammenkommen.

Properties: Was über das Minimum hinausgeht

Die BACnet-Norm unterscheidet zwischen Required Properties (zwingend nach Standard) und Optional Properties. In der Praxis entscheidet die Ausschreibung, welche optionalen Properties trotzdem geliefert werden müssen:

Description

Das Property Description ist optional, aber für den Betrieb unverzichtbar. Es enthält eine menschenlesbare Beschreibung des Datenpunkts, zum Beispiel «Zulufttemperatur AHU 2.1, nach Nacherhitzer». Ohne Description ist der Betreiber auf den Object_Name angewiesen, der nach Namenskonvention oft kryptisch ist.

Reliability und Status_Flags

Diese Properties zeigen an, ob ein Datenpunkt vertrauenswürdig ist (Sensor defekt, Drahtbruch, Out_Of_Service). Ohne sie sieht der Betreiber einen Temperaturwert von 0.0 °C und weiss nicht, ob das ein realer Messwert ist oder ein Sensorfehler.

COV_Increment

Bestimmt, bei welcher Wertänderung ein Gerät automatisch eine COV-Nachricht sendet. Ohne Vorgabe wählt der Hersteller Defaultwerte, die für das Projekt möglicherweise zu grob oder zu fein sind.

Active_Text / Inactive_Text

Für binäre Objekte: Was bedeutet «aktiv» (z. B. «Pumpe EIN»), was «inaktiv» (z. B. «Pumpe AUS»)? Ohne Vorgabe entscheidet der Integrator, und verschiedene Integratoren verwenden verschiedene Texte für dieselbe Funktion.

Dienste (Services): Was das Gerät können muss

Neben Objekten und Properties definiert BACnet eine Reihe von Diensten (Services), die den Datenaustausch steuern. Der Planer muss festlegen, welche Dienste ein Gerät unterstützen muss. Die KBOB-Empfehlung fasst die relevanten Dienste in sogenannten BIBBs zusammen.

Die wichtigsten BIBBs für Automationsstationen:

• DS-RP-B / DS-WP-B (Data Sharing): Lesen und Schreiben einzelner Properties. Grundvoraussetzung für jede Integration.
• DS-COV-B (COV): Automatische Benachrichtigung bei Wertänderungen. Reduziert die Netzwerklast gegenüber Polling erheblich.
• AE-N-B (Alarm & Event): Senden von Alarmmeldungen an andere Geräte oder das Leitsystem.
• T-VMT-B (Trending): Bereitstellung aufgezeichneter Trenddaten zum Abruf durch das Leitsystem.
• SCHED-B (Scheduling): Verwaltung von Zeitprogrammen auf dem Gerät.

Ohne BIBB-Vorgaben kann ein Gerät BACnet sprechen, aber wesentliche Betriebsfunktionen nicht ausführen. Ein Controller ohne AE-N-B kann keine Alarme senden. Einer ohne T-VMT-B kann keine Trenddaten liefern. Die Ausschreibung muss diese Anforderungen explizit benennen.

Protokoll-Revision: die unsichtbare Mindestanforderung

Neben Profilen, Objekttypen und BIBBs gibt es eine weitere Vorgabe, die in keiner Ausschreibung fehlen darf: die Mindest-Protokoll-Revision.

BACnet wird in regelmässigen Abständen weiterentwickelt. Jede Revision bringt neue Objekttypen, neue Properties und neue Dienste. Ein Gerät, das auf Revision 1.10 basiert, kennt zum Beispiel noch kein Trend Log Multiple, kein Structured View und kein Network Port Object. Es fehlen also Funktionen, die in modernen Anlagen unverzichtbar sind.

Die KBOB-Empfehlung fordert mindestens Revision 1.14. Einzelne Institutionen wie das Universitätsspital Zürich verlangen Revision 1.18, weil erst ab dieser Revision bestimmte Sicherheits- und Netzwerkfunktionen vollständig unterstützt werden.

Ohne Revisionsvorgabe liefert der Anbieter, was er am Lager hat. Und das kann ein Controller mit einer zehn Jahre alten Firmware sein, der formal BACnet-konform ist, aber wichtige Funktionen schlicht nicht beherrscht. Die Angabe der Mindestrevision gehört deshalb in jedes GA-Leistungsverzeichnis.

Von der Vorgabe zur Prüfung: EDE und PICS

Objektvorgaben nützen nur dann etwas, wenn sie bei der Abnahme überprüfbar sind. Dafür gibt es zwei standardisierte Werkzeuge:

EDE (Engineering Data Exchange): Ein tabellarisches Format, in dem der Systemintegrator alle konfigurierten BACnet-Objekte dokumentiert, mit Object_Name, Object_Type, Description, Unit und weiteren Properties. Die EDE-Tabelle ist das zentrale Nachweisdokument bei der Abnahme. Die KBOB-Empfehlung fordert sie explizit.

PICS (Protocol Implementation Conformance Statement): Ein Herstellerdokument, das beschreibt, welche BACnet-Profile, Dienste und Objekttypen ein Gerät unterstützt. Zusammen mit einem BTL-Listing (BACnet Testing Laboratories) gibt das PICS Auskunft darüber, ob ein Gerät die geforderten Anforderungsprofile erfüllt.

Der Planer sollte in der Ausschreibung beide Dokumente einfordern: das PICS als Nachweis der Gerätefähigkeiten und die EDE-Tabelle als Nachweis der projektspezifischen Konfiguration. Teil 6 dieser Serie vertieft den Abnahmeprozess im Detail.

Aus der Praxis: die häufigsten Fehler bei Objektvorgaben

• Keine Namenskonvention im Leistungsverzeichnis. Ohne Vorgabe für Object_Name benennt jeder Integrator anders. Resultat: unleserliche Datenpunktlisten, die nachträglich kaum noch harmonisierbar sind.
• Trend Logs nicht vorgeschrieben. Der Integrator legt keine an, weil es nicht gefordert wurde. Der Betreiber hat keine historischen Daten für Optimierung und Nachweispflichten.
• Nur Leitsystem-Alarme. Alarme werden nur auf dem Leitsystem konfiguriert, nicht auf den Geräten. Bei Leitsystemausfall gehen alle Alarmmeldungen verloren.
• Device-IDs nicht koordiniert. Zwei Hersteller verwenden denselben ID-Bereich. Beim Zusammenschalten der Netze kollidieren die Geräte.
• Keine Vorgaben für Units und State_Text. Temperaturen mal in Celsius, mal in Fahrenheit. Betriebsmodi mal in Deutsch, mal in Englisch, mal als Nummern.

Wichtig: Die KBOB-Empfehlung «BACnet Anwendung» (2021) definiert die Anforderungsprofile AS-CH und MBE-CH als Mindeststandard für öffentliche Bauten. Auch die AMEV «BACnet 2017» bietet mit ihren Profilen AS-A und AS-B praxisnahe Checklisten für die Ausschreibung. Ergänzend liefert die VDI 3814 Blatt 2.1 methodische Hilfe für die Bedarfsplanung und die Formulierung von Lastenheften.

Objektvorgaben strukturiert formulieren

Wie bringt der Planer all diese Anforderungen in ein Leistungsverzeichnis? Bewährt hat sich eine dreistufige Struktur:

Stufe 1, Systemanforderungen: Mindest-Protokoll-Revision, gefordertes Anforderungsprofil (z. B. AS-CH), geforderte BIBBs, Mindestanzahl Schedule- und Calendar-Objekte pro Station.

Stufe 2, Objektspezifische Vorgaben: Pro Objekttyp eine Tabelle mit den geforderten Properties, Einheiten, Beschriftungsregeln und besonderen Anforderungen (z. B. COV_Increment für Temperaturen = 0.5 K).

Stufe 3, Nachweispflichten: Forderung nach EDE-Tabelle (Version 2.3 oder höher), PICS-Dokument, BTL-Listing und ggf. AMEV-Testat. Abgabezeitpunkte im Projektplan verankern.

Diese Struktur orientiert sich an der Methodik der VDI 3814 Blatt 2.1 und lässt sich gut mit den KBOB-Anforderungsprofilen kombinieren. Entscheidend ist, dass die Vorgaben nicht als Prosatext formuliert werden, sondern als prüfbare Tabellen und Checklisten, damit der Abnahmeprüfer später eindeutig feststellen kann, ob die Anforderungen erfüllt sind.

Fazit

Objektvorgaben sind der Kern jeder BACnet-Planung. Sie entscheiden darüber, ob eine Anlage im Betrieb funktioniert oder nur auf dem Papier BACnet spricht. Der Planer muss festlegen, welche Objekttypen angelegt, welche Properties befüllt und welche Dienste unterstützt werden müssen, und er muss diese Vorgaben in der Ausschreibung verbindlich formulieren.

Die KBOB-Anforderungsprofile AS-CH und MBE-CH bieten einen bewährten Ausgangspunkt. Sie stellen sicher, dass Automationsstationen und Leitsysteme die Funktionen mitbringen, die im Betrieb tatsächlich gebraucht werden: Alarme auf dem Gerät, Trends zum Abruf, Zeitprogramme im Controller.

Im nächsten Teil dieser Serie geht es um Datenpunktlisten und Beschriftungsregeln, die Strukturen, die dafür sorgen, dass alle diese Objekte auch lesbar, navigierbar und wartbar bleiben.

Diese Serie ergänzt unsere Serie «BACnet Objekte verstehen», die sich mit der technischen Mechanik der einzelnen Objekttypen befasst. Wer beide Serien kennt, versteht nicht nur, was BACnet-Objekte können, sondern auch, wie man sie richtig plant.

Sie haben Fragen dazu?

Sprechen Sie uns an, wir unterstützen Bauherren, Planer und Betreiber bei der professionellen BACnet-Planung, von der Bedarfsanalyse bis zur Abnahme.

WENGET GmbH E-Mail: info@wenget.ch Telefon: +41 44 552 34 88

Quellenverzeichnis

• KBOB, «Empfehlung BACnet Anwendung», Version 2.0, Juli 2021
• AMEV, «BACnet 2017», Arbeitskreis Maschinen- und Elektrotechnik staatlicher und kommunaler Verwaltungen
• ISO 16484-5, «Building automation and control systems: Part 5: Data communication protocol (BACnet)»
• VDI 3814 Blatt 2.1, «Gebäudeautomation: Bedarfsplanung», Verein Deutscher Ingenieure
• SIA 386, «Gebäudeautomation: Grundlagen», Schweizerischer Ingenieur- und Architektenverein