Datenpunktlisten & Beschriftungsregeln: Die unsichtbare Grundlage des Betriebs

Im zweiten Teil dieser Serie haben wir gezeigt, welche Objekttypen, Properties und Dienste der Planer vorschreiben muss. Doch selbst die beste Objektvorgabe nützt wenig, wenn die Datenpunkte in der Anlage kryptisch benannt und uneinheitlich strukturiert sind. Genau hier setzt dieser dritte Teil an: Datenpunktlisten und Beschriftungsregeln, die unsichtbare Grundlage des Betriebs.

Wer eine Gebäudeautomation betreibt, navigiert täglich durch Tausende von Datenpunkten. Temperaturen, Klappenstellungen, Pumpenstätus, Alarme, Sollwerte. Ob diese Punkte lesbar, filterbar und verständlich sind, entscheidet darüber, ob ein Betreiber seine Anlage versteht, oder ob er bei jeder Störung den Integrator anrufen muss. Die Grundlage dafür wird in der Planungsphase gelegt: durch eine durchdachte Namenskonvention, eine saubere Datenpunktstruktur und verbindliche Beschriftungsregeln.

Warum Namenskonventionen entscheidend sind

Der BACnet-Standard schreibt vor, dass jedes Objekt einen Object_Name haben muss. Er schreibt aber nicht vor, wie dieser Name aufgebaut sein soll. Das ist Sache des Planers.

Ohne Namenskonvention benennt jeder Systemintegrator seine Objekte nach eigener Logik. Ein Temperaturfühler in der Lüftungsanlage 2, Geschoss 1 könnte heissen:

• TMP_AHU2_1OG (Integrator A)
• AI_12 (Integrator B)
• L02-ZUL-TEMP (Integrator C)
• Zulufttemperatur Anlage 2 (Integrator D)

Alle vier Namen bezeichnen denselben physischen Datenpunkt, aber keiner ist ohne Kontextwissen verständlich, und keiner passt zu den anderen. Wenn in einer Liegenschaft zwei oder drei Integratoren arbeiten, entsteht ein Datenpunkt-Chaos, das sich im Betrieb kaum noch auflösen lässt.

Aufbau einer BACnet-Namenskonvention

Eine gute Namenskonvention für Object_Name folgt einem hierarchischen Aufbau. Bewährt hat sich eine Struktur, die sich an den Schweizer Anlagenkennzeichnungssystemen orientiert:

Segment 1: Liegenschaft / Gebäude

Ein Kürzel für die Liegenschaft oder das Gebäude. Beispiel: HB01 für Hauptgebäude 1.

Segment 2: Anlage / Gewerk

Ein Kürzel für die technische Anlage. Beispiel: LU01 für Lüftungsanlage 1, HZ02 für Heizkreis 2, KA01 für Kälteanlage 1.

Segment 3: Funktion / Aggregat

Was wird gemessen oder gesteuert? Beispiel: ZUL für Zuluft, ABL für Abluft, VL für Vorlauf, RL für Rücklauf.

Segment 4: Messgrösse / Typ

Was für ein Datenpunkt ist es? Beispiel: TEMP für Temperatur, DRUCK für Druck, KLAP für Klappenstellung, PMP für Pumpenstatus.

Das vollständige Namensbeispiel: HB01.LU01.ZUL.TEMP, Hauptgebäude 1, Lüftungsanlage 1, Zulufttemperatur. Jeder, der die Konvention kennt, versteht sofort, was dieser Datenpunkt misst.

Die Rolle des Anlagenkennzeichnungsschlüssels (AKS)

Der Anlagenkennzeichnungsschlüssel (AKS) ist ein systematisches Schema zur Identifikation technischer Anlagen und deren Komponenten. In der Schweiz und in Deutschland ist er in der Gebäudetechnik weit verbreitet. Die VDI 3814 Blatt 4.1 liefert eine detaillierte Methodik für den AKS in der Gebäudeautomation.

Der AKS bildet die Brücke zwischen der physischen Anlage und der BACnet-Datenpunktbezeichnung. Wenn der AKS früh im Projekt definiert wird, kann der Object_Name direkt aus dem AKS abgeleitet werden. Das stellt sicher, dass die Bezeichnungen in der BACnet-Welt mit den Bezeichnungen in Schemas, Datenpunktlisten und Gebäudeleitsystem übereinstimmen.

Ohne AKS-Vorgabe erstellt jeder Integrator seine eigene Nomenklatur. Das führt dazu, dass dieselbe Anlage im Schema anders heisst als im BACnet-Netzwerk und wieder anders im Leitsystem. Der Betreiber verliert die Rückverfolgbarkeit.

Datenpunktlisten: Struktur und Inhalt

Eine Datenpunktliste (DPL) ist das zentrale Planungsdokument für die Gebäudeautomation. Sie enthält jeden einzelnen Datenpunkt der Anlage mit seinen Eigenschaften. In der BACnet-Welt wird die Datenpunktliste häufig in Form einer EDE-Tabelle (Engineering Data Exchange) abgebildet.

Eine vollständige Datenpunktliste enthält mindestens:

• Object_Name: Bezeichnung nach Namenskonvention
• Object_Type: z. B. Analog Input, Binary Output, Multi-State Value
• Description: Klartextbeschreibung (z. B. «Zulufttemperatur nach Nacherhitzer, AHU 2.1»)
• Units: Physikalische Einheit (z. B. degrees-Celsius, percent)
• Anlage/Gewerk: Zuordnung zur technischen Anlage
• Standort: Gebäude, Geschoss, Raum
• Alarmkonfiguration: Grenzwerte, Priorität, Notification Class
• Trendkonfiguration: Aufzeichnungsintervall, COV oder Polling, Buffer_Size

Die KBOB-Empfehlung fordert die Abgabe einer EDE-Tabelle (Version 2.3 oder höher) als Nachweis bei der Abnahme. Die AMEV «BACnet 2017» enthält in Anhang 7 detaillierte Planungshilfen für die Zuordnung von GA-Funktionen zu BACnet-Objekttypen.

Beschriftungsregeln für Properties

Neben dem Object_Name gibt es weitere Properties, für die der Planer Beschriftungsregeln definieren sollte:

Description

Das Property Description ergänzt den Object_Name um eine menschenlesbare Beschreibung. Während der Object_Name kodiert ist (HB01.LU01.ZUL.TEMP), enthält die Description den Klartext: «Zulufttemperatur Lüftungsanlage 1, nach Nacherhitzer». Der Planer sollte vorschreiben, in welcher Sprache und welchem Format Descriptions zu liefern sind.

Active_Text und Inactive_Text

Für binäre Objekte (BI, BO, BV) definiert der Planer, was «aktiv» und «inaktiv» bedeutet. Beispiel: Active_Text = «Pumpe EIN», Inactive_Text = «Pumpe AUS». Ohne Vorgabe verwenden verschiedene Integratoren verschiedene Texte, oder nur die Defaultwerte «active» und «inactive».

State_Text (Multi-State Objekte)

Für Multi-State Objekte (MSI, MSO, MSV) legt der Planer die Zustandstexte fest. Beispiel für einen Betriebsmodus: State 1 = «AUS», State 2 = «Heizen», State 3 = «Kühlen», State 4 = «Standby». Ohne Vorgabe kann State 1 bei einem Hersteller «Auto» bedeuten und bei einem anderen «Off».

Units

Physikalische Einheiten müssen einheitlich festgelegt werden. Temperaturen in degrees-Celsius (nicht Fahrenheit), Drücke in Kilopascal oder Bar (nicht PSI), Volumenstrom in Kubikmeter pro Stunde. Die BACnet-Norm definiert eine umfangreiche Liste von Engineering Units, der Planer wählt die für das Projekt gültigen aus.

Taxonomie: Datenpunkte sinnvoll gruppieren

Eine gute Namenskonvention allein reicht nicht. Die Datenpunkte müssen auch sinnvoll gruppiert werden, damit der Betreiber sie navigieren kann. BACnet bietet dafür das Structured View Object, das Datenpunkte hierarchisch organisiert, ähnlich wie Ordner in einem Dateisystem.

Der Planer sollte vorgeben, wie die Strukturierung aufgebaut sein soll: nach Gebäude, Geschoss, Anlage oder nach Funktion. Die Wahl der Taxonomie hängt davon ab, wie der Betreiber die Anlage navigiert. In grossen Liegenschaften mit mehreren Gebäuden ist eine Standort-basierte Hierarchie meist sinnvoller. In Anlagen mit vielen gleichartigen Systemen (z. B. Rechenzentren) kann eine funktionale Gruppierung besser sein.

Entscheidend ist, dass die Taxonomie früh definiert und in der Ausschreibung vorgeschrieben wird. Nachträgliches Umstrukturieren von Datenpunktbäumen ist aufwändig und fehleranfällig. Auch die Namensgebung der Views selbst sollte geregelt sein, ein einheitliches Präfix wie VIEW_ oder eine funktionale Kennzeichnung verhindert Verwechslungen mit regulären BACnet-Objekten.

Datenpunktliste und EDE: zwei Seiten derselben Medaille

In der Planungsphase dient die Datenpunktliste als Vorgabedokument: Der Planer definiert, welche Datenpunkte die Anlage haben soll, wie sie heissen, welche Properties sie mitbringen und wie sie konfiguriert werden müssen. Das ist die Soll-DPL.

Bei der Abnahme liefert der Systemintegrator die EDE-Tabelle (Engineering Data Exchange), die Ist-DPL. Sie zeigt, welche BACnet-Objekte tatsächlich konfiguriert wurden. Der Abgleich zwischen Soll-DPL und EDE-Tabelle ist der zentrale Prüfschritt bei der BACnet-Abnahme.

Damit dieser Abgleich funktioniert, müssen beide Dokumente auf derselben Namenskonvention basieren. Wenn der Planer in der Soll-DPL HB01.LU01.ZUL.TEMP schreibt und der Integrator in der EDE Zuluft_Temp_AHU1 liefert, scheitert der automatisierte Vergleich. Deshalb muss die Namenskonvention nicht nur definiert, sondern auch vertraglich als verbindliche Schnittstelle zwischen Planung und Ausführung festgelegt werden.

Sprache und Zeichensatz

Ein oft übersehener Punkt: In welcher Sprache werden Descriptions, State_Texts und Active_Texts geschrieben? In internationalen Projekten kann Englisch sinnvoll sein. In Schweizer Liegenschaften, die von lokalem Betriebspersonal geführt werden, ist Deutsch (oder Französisch/Italienisch, je nach Region) die bessere Wahl.

Der Planer sollte die Sprache in den Beschriftungsregeln explizit festlegen. Ebenso den Zeichensatz: BACnet unterstützt UTF-8, aber nicht alle älteren Geräte und Leitsysteme können Umlaute oder Sonderzeichen korrekt darstellen. In der Praxis hat sich bewährt, Object_Names auf ASCII-Zeichen zu beschränken (also UE statt Ü, AE statt Ä) und Umlaute nur in Descriptions und State_Texts zuzulassen, wo die Darstellung weniger kritisch ist.

Versionierung und Änderungsmanagement

Datepunktlisten sind lebende Dokumente. Während der Planungsphase werden Datenpunkte ergänzt, umbenannt oder gestrichen. In der Realisierungsphase kommen hardwarespezifische Anpassungen hinzu. Ohne Versionierung verliert das Projektteam den Überblick darüber, welche Version der DPL aktuell gültig ist.

Der Planer sollte deshalb ein Änderungsmanagement für die DPL vorschreiben: Versionsnummern, Änderungsdatum, verantwortliche Person und eine kurze Beschreibung der Änderung. Das klingt bürokratisch, spart aber bei Nachträgen und Streitfällen erheblichen Aufwand.

Konsistenz über Gewerke und Hersteller hinweg

In vielen Projekten arbeiten mehrere Systemintegratoren parallel: einer für Lüftung, einer für Heizung/Kälte, einer für Beleuchtung oder Beschattung. Jeder bringt seine eigenen Gewohnheiten mit.

Ohne übergreifende Beschriftungsregeln und Datenpunktkonventionen entsteht ein Flickenteppich: Anlage 1 heisst AHU_01, Anlage 2 heisst Lueft_02, Anlage 3 heisst L-003. Die Namenskonvention muss deshalb projektweite Gültigkeit haben und vertraglich verbindlich sein, für jeden Unternehmer, der BACnet-Geräte liefert.

Die Rolle des BACnet-Koordinators (siehe Teil 6 dieser Serie) ist hier zentral: Er stellt sicher, dass alle Integratoren dieselben Regeln anwenden und prüft die Einhaltung vor der Abnahme.

Ein pragmatischer Ansatz: Der BACnet-Koordinator definiert ein verbindliches «Naming-Sheet», ein einseitiges Dokument, das die Segmentierung, die erlaubten Kürzel und drei bis fünf Beispieldatenpunkte enthält. Jeder Integrator erhält dieses Sheet als Vertragsbestandteil. Bei der Abnahme wird gegen dieses Sheet geprüft. Das ist einfacher und wirkungsvoller als seitenlange Richtliniendokumente, die in der Praxis niemand liest.

Ebenso wichtig: Der Koordinator prüft frühzeitig Stichproben der Datenpunktbezeichnungen, nicht erst bei der Abnahme. Eine Kontrolle nach der Konfiguration von 20 Prozent der Datenpunkte deckt Missverständnisse auf, bevor sie sich auf die gesamte Anlage ausbreiten.

Aus der Praxis: die häufigsten Fehler bei Datenpunktlisten

• Keine projektweite Namenskonvention. Drei Integratoren, drei Logiken. Das Leitsystem zeigt einen Datenpunktdschungel.
• Description leer gelassen. Der Object_Name ist kodiert, die Description fehlt. Der Betreiber sieht HB01.HZ02.VL.TEMP und weiss nicht, ob das der Heizungsvorlauf oder der Warmwasservorlauf ist.
• State_Text nicht vereinheitlicht. Betriebsmodus «Heizen» heisst bei Hersteller A «Heating», bei Hersteller B «HTG», bei Hersteller C «2». Reports und Auswertungen werden unbrauchbar.
• Kein AKS definiert. Die Datenpunktbezeichnungen im BACnet passen nicht zu den Schemata und nicht zum Leitsystem. Die Rückverfolgbarkeit fehlt.
• Datenpunktliste erst bei Abnahme erstellt. Statt in der Planungsphase wird die DPL erst bei der Inbetriebnahme zusammengestellt: als Dokumentation des Ist-Zustands statt als Planungswerkzeug.

Wichtig: Die KBOB-Empfehlung «BACnet Anwendung» (2021) fordert die Abgabe einer EDE-Tabelle als standardisiertes Nachweisdokument. Die VDI 3814 Blatt 4.1 liefert den methodischen Rahmen für den Anlagenkennzeichnungsschlüssel (AKS). Beide Dokumente zusammen bilden das Rückgrat einer professionellen Datenpunktplanung.

Werkzeuge für die Datenpunktplanung

In der Praxis werden Datenpunktlisten meist in Tabellenkalkulationen (Excel, Google Sheets) geführt. Das funktioniert für kleinere Projekte. Für grössere Liegenschaften mit mehreren Tausend Datenpunkten empfiehlt sich eine datenbankgestützte Lösung, die Namenskonventionen automatisch validiert, Duplikate erkennt und den Export in das EDE-Format unterstützt.

Einige Leitsystemhersteller bieten eigene Engineering-Tools an, die Datenpunktlisten direkt in die BACnet-Konfiguration überführen können. Der Nachteil: Diese Tools sind oft herstellerspezifisch und erzeugen eine Abhängigkeit, die dem offenen BACnet-Gedanken widerspricht. Der Planer sollte deshalb ein herstellerunabhängiges Format für die Soll-DPL vorschreiben, idealerweise das EDE-Format selbst oder ein strukturiertes CSV/Excel-Template, das in EDE konvertierbar ist.

Die AMEV «BACnet 2017» stellt in Anhang 3 eine Zuordnungstabelle bereit, die GA-Funktionen nach ISO 16484-3 den entsprechenden BACnet-Objekttypen zuordnet. Diese Tabelle ist ein wertvolles Arbeitsmittel für den Planer, der seine Datenpunktliste systematisch aufbauen will.

Fazit

Datenpunktlisten und Beschriftungsregeln sind die unsichtbare Grundlage einer wartbaren Gebäudeautomation. Sie entscheiden darüber, ob ein Betreiber seine Anlage versteht, navigieren und optimieren kann, oder ob er bei jeder Frage auf den Systemintegrator angewiesen ist.

Der Schlüssel liegt in der frühen Festlegung: Namenskonvention, AKS, Beschriftungsregeln für Properties und Taxonomie müssen in der Planungsphase definiert und in der Ausschreibung verbindlich vorgeschrieben werden. Nachträgliches Harmonisieren ist um ein Vielfaches teurer als die saubere Vorgabe.

Im nächsten Teil dieser Serie geht es um die BACnet-Netzwerkplanung: Segmentierung, Routerplatzierung, Adressverwaltung und Performance-Reserven.

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
• VDI 3814 Blatt 4.1, «Gebäudeautomation: Arbeitsmittel, Anlagenkennzeichnungsschlüssel», Verein Deutscher Ingenieure
• AMEV, «BACnet 2017», Anhang 7 (Planungshilfen), Arbeitskreis Maschinen- und Elektrotechnik staatlicher und kommunaler Verwaltungen
• ISO 16484-5, «Building automation and control systems: Part 5: Data communication protocol (BACnet)»
• SIA 386, «Gebäudeautomation: Grundlagen», Schweizerischer Ingenieur- und Architektenverein