Herstellerunabhängigkeit im Gebäudebetrieb: Wie viel Freiheit bietet BACnet wirklich?

BACnet verspricht Herstellerunabhängigkeit. Es ist ein offener, ISO-normierter Standard, unterstützt von Hunderten von Herstellern weltweit, getestet und zertifiziert durch BACnet International. Die KBOB-Empfehlung in der Schweiz setzt auf BACnet als Referenzstandard für die Gebäudeautomation öffentlicher Bauten. In der Theorie könnte ein Bauherr jeden Controller, jedes Leitsystem und jeden Servicepartner frei wählen, und jederzeit wechseln. In der Praxis sieht das anders aus. Trotz BACnet entstehen Abhängigkeiten: durch proprietäre Erweiterungen, durch fehlende Profile, durch undokumentierte Implementierungen und durch vertragliche Konstrukte, die den offenen Standard faktisch aushebeln. Dieser Artikel ist ein ehrlicher Reality-Check: Was leistet BACnet in Sachen Herstellerunabhängigkeit tatsächlich, und wo bleibt das Versprechen eine Illusion, wenn Planer und Bauherren nicht aktiv gegensteuern?

Das Versprechen: Was BACnet ermöglichen soll

BACnet (Building Automation and Control Networks) wurde entwickelt, um die Interoperabilität in der Gebäudeautomation sicherzustellen. Der Standard definiert ein gemeinsames Kommunikationsprotokoll mit standardisierten Objekttypen, Diensten und Netzwerkschichten. Ein BACnet-konformes Gerät soll mit jedem anderen BACnet-konformen Gerät kommunizieren können, unabhängig vom Hersteller.

Die Vorteile liegen auf der Hand: Wettbewerb bei Ersatzinvestitionen, freie Wahl des Servicepartners, Unabhängigkeit von einem einzigen Hersteller für den gesamten Lebenszyklus. Für Bauherren bedeutet das tiefere Betriebskosten, höhere Flexibilität und weniger Risiko. Für Planer bedeutet es die Möglichkeit, die jeweils beste Lösung pro Gewerk auszuwählen, ohne Schnittstellenprobleme befürchten zu müssen.

Dieses Versprechen ist real, aber es ist an Voraussetzungen geknüpft, die in der Praxis häufig nicht erfüllt sind. Dieser Artikel beleuchtet beide Seiten: Wo BACnet das Versprechen einlöst, wo es an Grenzen stösst und was Planer und Bauherren tun müssen, damit echte Herstellerunabhängigkeit nicht nur ein theoretischer Vorteil bleibt.

Wo BACnet sein Versprechen einlöst

In bestimmten Bereichen funktioniert die Herstellerunabhängigkeit tatsächlich gut. Auf der Ebene der Basiskommunkation, also dem Lesen und Schreiben von Standard-Datenpunkten wie Analog Input, Binary Output oder Multi-State Value, ist die Interoperabilität in der Praxis zuverlässig. Ein BACnet-Leitsystem kann die Raumtemperatur eines Drittanbieter-Controllers auslesen, einen Ventilantrieb steuern oder den Status einer Lüftungsanlage abfragen, sofern beide Seiten die grundlegenden ReadProperty- und WriteProperty-Dienste unterstützen.

Auch auf der Ebene der Geräteerkennung (Who-Is/I-Am) und der Basisdienste funktioniert BACnet herstellerübergreifend zuverlässig. Ein Netzwerkscan mit YABE oder einem kommerziellen BACnet-Browser findet Geräte unabhängig vom Hersteller und zeigt deren Objektlisten an. Diese grundlegende Transparenz ist ein wesentlicher Vorteil offener Protokolle und funktioniert in der Praxis zuverlässig.

Für einfache Anwendungsfälle, Datenpunkte lesen, Sollwerte setzen, Zustände überwachen, ist BACnet damit tatsächlich herstellerübergreifend nutzbar. In vielen Projekten bildet diese Basisfunktionalität bereits einen erheblichen Mehrwert: Die Möglichkeit, alle Gewerke in einem einzigen Leitsystem zusammenzuführen, herstellerunabhängig Energiedaten zu sammeln oder Raumautomation zentral zu überwachen, ist ein realer Gewinn gegenüber geschlossenen Systemen.

Das Problem beginnt dort, wo die Anforderungen über diese Basisfunktionalität hinausgehen, und das ist in der Praxis häufiger der Fall, als viele Planer erwarten.

Wo die Herstellerunabhängigkeit scheitert

Proprietäre Objekte und Vendor-spezifische Erweiterungen

BACnet erlaubt Herstellern, eigene Objekttypen und Properties zu definieren, sogenannte Vendor-spezifische Objekte (Objekttyp 128–255) und Vendor-spezifische Properties. Viele Hersteller nutzen diese Möglichkeit extensiv: Konfigurationsparameter, Diagnosefunktionen, erweiterte Regellogik und proprietäre Betriebsmodi werden über nicht-standardisierte Objekte abgebildet.

Das Problem: Diese Objekte sind für Drittsysteme nicht interpretierbar. Ein Leitsystem eines anderen Herstellers sieht zwar, dass ein Vendor-spezifisches Objekt existiert, kann aber dessen Bedeutung nicht erkennen. Die Folge: Erweiterte Funktionen, oft genau die Funktionen, die den Mehrwert der Anlage ausmachen, sind nur mit dem Originalsystem des Herstellers nutzbar. Der Bauherr ist für diese Funktionen de facto an den Hersteller gebunden.

Konkret heisst das: Energiemonitoringdaten, die über proprietäre Objekte bereitgestellt werden, können bei einem Leitsystemwechsel nicht ohne Weiteres migriert werden. Komplexe Regelstrategien, die über Vendor-spezifische Logikblöcke realisiert wurden, müssen beim neuen System vollständig neu programmiert werden. Was wie eine «offene» BACnet-Anlage aussieht, enthält in der Tiefe oft erhebliche proprietäre Anteile, die einen Wechsel verteuern und verzichern.

Fehlende oder minimale Profile

BACnet definiert Geräteprofile (B-ASC, B-AAC, B-AWS etc.), die festlegen, welche Objekttypen und Dienste ein Gerät mindestens unterstützen muss. In der Praxis implementieren viele Geräte nur das absolute Minimum ihres Profils, oder deklarieren ein Profil, ohne es vollständig zu erfüllen. Besonders bei älteren Geräten oder Einsteigerprodukten fehlen oft Dienste wie ReadPropertyMultiple, COV-Subscriptions oder Trendlog-Objekte.

Für den Bauherrn bedeutet das: Ein Gerät, das «BACnet-konform» ist, unterstützt möglicherweise nicht die Funktionen, die für eine sinnvolle Integration erforderlich sind. Die Konformität bezieht sich nur auf das deklarierte Profil und die deklarierten Dienste, nicht auf den vollständigen BACnet-Funktionsumfang.

Besonders problematisch ist die Situation bei Mischinstallationen: Wenn ein Gewerk Controller mit B-ASC-Profil einsetzt und das übergeordnete System ReadPropertyMultiple für die effiziente Datenpunktabfrage voraussetzt, dieses Feature aber bei einigen Controllern fehlt, fällt das System auf langsames Einzel-Polling zurück. Die Anlage funktioniert, aber die Performance und der Bedienkomfort leiden spürbar. Solche Inkompatibilitäten lassen sich nur durch präzise Profilspezifikation in der Ausschreibung vermeiden.

Undokumentierte Implementierungsdetails

BACnet lässt in vielen Bereichen Implementierungsspielraum. Wie eine Regellogik intern arbeitet, wie Sollwerte priorisiert werden, wie Schedule-Objekte mit lokalen Übersteuerungen interagieren oder wie ein Controller bei Kommunikationsausfall reagiert, all das ist vom Standard nicht vollständig festgelegt. Jeder Hersteller implementiert diese Details anders.

Bei einem Herstellerwechsel bedeutet das: Selbst wenn alle BACnet-Datenpunkte korrekt übertragen werden, kann sich das Anlagenverhalten ändern, weil die interne Logik anders arbeitet. Das ist kein BACnet-Problem im engeren Sinne, BACnet standardisiert die Kommunikation, nicht die Applikation. Aber es ist ein reales Problem für die Herstellerunabhängigkeit, weil ein Wechsel eben doch nicht so einfach ist, wie der Standard suggeriert.

Ein konkretes Beispiel: Die Sollwertpriorisierung gemäss BACnet Priority Array definiert 16 Prioritätsstufen. Wie ein Controller auf gleichzeitige Schreibzugriffe verschiedener Prioritäten reagiert, welche Standardwerte er bei Ablauf eines Overrides einsetzt und wie er die Relinquish-Default-Logik handhabt, das variiert zwischen Herstellern. Bei einem Wechsel müssen diese Verhaltensdetails einzeln geprüft und angepasst werden.

Vertragliche Lock-ins

Nicht alle Abhängigkeiten sind technischer Natur. In vielen Projekten entstehen Lock-ins durch Vertragskonstrukte: exklusive Wartungsverträge, proprietäre Engineering-Tools, die nur der Hersteller lizenziert, oder Softwarelizenzen, die an bestimmte Hardware gebunden sind. Selbst wenn die BACnet-Schnittstelle offen ist, kann der Zugang zur Konfigurationsebene des Controllers durch proprietäre Tools gesperrt sein.

Ein typisches Beispiel: Der Controller kommuniziert über BACnet, aber die Programmierung erfolgt über ein herstellerspezifisches Engineering-Tool. Ein Wechsel des Servicepartners ist nur möglich, wenn dieser über die entsprechende Lizenz und Schulung verfügt, was die Auswahl faktisch auf Partner des gleichen Herstellers einschränkt.

Weitere vertragliche Fallstricke: Firmware-Updates, die nur über den Hersteller-Cloud-Service verfügbar sind, Support-Verträge, die an den Erstinstallateur gekoppelt sind, oder Datenbank-Backups des Leitsystems, die nur mit der Originallizenzsoftware wiederhergestellt werden können. All diese Konstrukte sind mit einem offenen BACnet-Netzwerk kompatibel, und untergraben trotzdem die Herstellerunabhängigkeit auf Ebene der Betriebsführung.

Was in die Ausschreibung gehört

Herstellerunabhängigkeit entsteht nicht automatisch durch die Spezifikation von BACnet. Sie muss aktiv in der Ausschreibung verankert werden. Die folgenden Punkte sind dabei zentral:

• BACnet-Profile verbindlich festlegen: Nicht nur «BACnet-fähig» fordern, sondern konkrete Profile (B-ASC, B-AAC, B-AWS) pro Gewerk.
• BTL-Listing als Pflicht: Nur Geräte akzeptieren, die auf der BTL-Produktliste von BACnet International geführt werden.
• Keine Vendor-spezifischen Objekte für Kernfunktionen: Vertraglich festlegen, dass alle für den Betrieb relevanten Funktionen über Standard-BACnet-Objekte abgebildet werden.
• Offene Engineering-Tools: Fordern, dass die Konfiguration der Controller mit herstellerunabhängigen oder zumindest frei zugänglichen Tools möglich ist.
• Dokumentationspflicht: Vollständige Datenpunktlisten, PICS-Datenblätter und Netzwerkdokumentation als vertragliche Lieferpflicht.
• Unabhängige Abnahme: Die BACnet-Konformität durch einen unabhängigen Prüfer bestätigen lassen.

Diese Anforderungen sind keine Überspezifikation. Sie sind die Minimalvoraussetzung dafür, dass das Versprechen der Herstellerunabhängigkeit in der Praxis überhaupt einlösbar wird.

Ein weiterer, oft übersehener Punkt: Die Anforderung an offene Engineering-Tools ist besonders relevant für den langfristigen Betrieb. Wenn nach zehn Jahren Betriebsdauer ein Controller ersetzt oder umprogrammiert werden muss, sollte der Betreiber nicht darauf angewiesen sein, dass genau der ursprüngliche Installateur mit genau der ursprünglichen Softwareversion verfügbar ist. Werkzeuge, die auf offenen Standards basieren, wie FTP-basierter Konfigurationszugang oder standardisierte EDE-Files (Engineering Data Exchange), erhöhen die Zukunftssicherheit der Anlage erheblich.

WENGET empfiehlt Bauherren, die Frage der Herstellerunabhängigkeit bereits im Vorprojekt zu adressieren und als explizites Projektziel zu formulieren. Wer das erst in der Ausschreibungsphase thematisiert, hat oft bereits Vorentscheide getroffen, die den Handlungsspielraum einschränken. Und wer das Thema erst im Betrieb entdeckt, wenn der erste Herstellerwechsel ansteht, zahlt den höchsten Preis: Zeit, Geld und Nerven für eine Migration, die bei besserer Planung vermeidbar gewesen wäre.

Das BTL-Listing als Mindestanforderung

Das BACnet Testing Laboratory (BTL) von BACnet International prüft Geräte auf Konformität zum BACnet-Standard gemäss ISO 16484-6. Ein BTL-gelistetes Gerät hat nachweislich die Tests bestanden, die sein deklariertes Profil und seine deklarierten Dienste verifizieren. Das BTL-Listing ist damit der verlässlichste, wenngleich nicht perfekte, Indikator für echte BACnet-Konformität.

In der Ausschreibung sollte das BTL-Listing als Mindestanforderung für alle BACnet-Geräte verankert werden. Die Aussage eines Herstellers, sein Gerät «unterstütze BACnet», ist ohne BTL-Listing nicht belastbar, denn sie sagt nichts darüber aus, welche Profile und Dienste tatsächlich implementiert und getestet sind.

Wichtig ist dabei, dass das BTL-Listing die spezifische Produktvariante und Firmware-Version abdeckt. Ein BTL-Listing für eine ältere Firmware-Version garantiert nicht, dass die aktuelle Version identisch konform ist. In der Ausschreibung sollte deshalb explizit gefordert werden, dass das BTL-Listing für die angebotene Produktkonfiguration und Firmware-Version gültig ist.

Praxistest: Herstellerwechsel im Bestand

Wie realistisch ist ein Herstellerwechsel in einer bestehenden BACnet-Anlage? Die ehrliche Antwort: Es kommt darauf an, wie die Anlage spezifiziert und dokumentiert wurde.

Ist die Datenpunktstruktur sauber dokumentiert, sind die BACnet-Objekte standardkonform implementiert und liegen PICS-Datenblätter vor, dann ist ein Austausch einzelner Controller oder eines Gewerks durchaus möglich. Die neuen Geräte müssen dieselben BACnet-Objekte mit denselben Instanznummern und Beschreibungen bereitstellen, und das übergeordnete System kann ohne Änderung weiterarbeiten.

Ist die Anlage dagegen auf proprietäre Funktionen angewiesen, fehlt die Dokumentation oder sind die Engineering-Tools herstellergebunden, wird ein Wechsel zum Sanierungsprojekt: Neuprogrammierung, Neuinbetriebnahme, Neuabnahme. Die Kosten übersteigen dann häufig den reinen Hardwaretausch um ein Vielfaches.

Genau hier zeigt sich der langfristige Wert einer sauberen BACnet-Spezifikation: Sie ist nicht nur ein Planungsdokument, sondern eine Versicherung gegen zukünftige Lock-ins.

Querverweise zu unseren Fachserien

• Proprietär vs. Offen (BAC-01): Der Einstiegsartikel erklärt, warum offene Standards wie BACnet die Grundlage für herstellerunabhängige Gebäudeautomation bilden, dieser Artikel zeigt die Grenzen dieses Ansatzes.
• KBOB BACnet-Empfehlung (BAC-02): Die KBOB-Empfehlung setzt den Rahmen, aber löst das Problem der proprietären Erweiterungen nicht.
• BACnet-Abnahme (BAC-04): Die unabhängige Abnahme ist das zentrale Instrument, um Herstellerunabhängigkeit in der Praxis durchzusetzen.
• BACnet Planung (BPL-Serie): Die Planungsserie zeigt, wie Profil- und BIBB-Anforderungen von Anfang an korrekt spezifiziert werden.

Fazit

BACnet schafft die technische Voraussetzung für Herstellerunabhängigkeit, aber es garantiert sie nicht. Wer sich auf den Standard allein verlässt, ohne in der Ausschreibung konkrete Anforderungen zu definieren und in der Abnahme deren Einhaltung zu prüfen, wird trotz BACnet in Abhängigkeiten geraten. Die Verantwortung liegt bei Planern und Bauherren: Sie müssen die richtigen Fragen stellen, die richtigen Anforderungen formulieren und die richtigen Prüfungen einfordern. BACnet ist ein mächtiges Werkzeug, aber ein Werkzeug muss richtig eingesetzt werden, um seinen Zweck zu erfüllen. Der Aufwand lohnt sich, auf den ganzen Lebenszyklus gerechnet.

Die zentrale Erkenntnis dieses Reality-Checks: Herstellerunabhängigkeit ist kein Zustand, sondern ein Prozess. Sie beginnt mit der Ausschreibung, wird in der Abnahme geprüft und muss im Betrieb durch konsequente Dokumentation und Vertragsgestaltung aufrechterhalten werden. Wer diesen Prozess ernst nimmt, erhält mit BACnet tatsächlich eine offene, flexible und zukunftssichere Gebäudeautomation. Wer ihn vernachlässigt, erhält ein System, das zwar BACnet spricht, aber trotzdem an einen Hersteller gebunden ist.

Sie haben Fragen dazu?

WENGET berät Sie bei der Formulierung herstellerunabhängiger BACnet-Anforderungen in Ausschreibungen und unterstützt Sie bei der Durchsetzung in der Abnahme. Ob Neuanlage oder Bestand: Wir sorgen dafür, dass BACnet sein Versprechen hält. Kontaktieren Sie uns für eine unverbindliche Erstberatung, wir analysieren Ihre bestehende Installation auf Herstellerabhängigkeiten und zeigen konkrete Handlungsoptionen auf.

Quellenverzeichnis

• ASHRAE Standard 135-2020: BACnet, A Data Communication Protocol for Building Automation and Control Networks
• ISO 16484-5: Building Automation and Control Systems, Data Communication Protocol (BACnet)
• ISO 16484-6: BACnet, Conformance Testing
• BACnet International: BTL Product Listing (btl.org)
• BACnet International: Interoperability Guidelines
• KBOB: Empfehlung «BACnet Anwendung», Version 2.0, Juli 2021
• BIG-EU: Leitfaden BACnet in Europa