Datenpunktbezeichnung: Warum der Name eines Datenpunkts Geld spart

Wer schon einmal eine Gebäudeautomationsanlage übernommen hat, kennt das Problem: Die Datenpunktliste enthält Hunderte von Einträgen, aber die Namen sagen wenig aus. «AI_01», «Temp_R3», «Ventil_links» oder «Pumpe neu» sind keine Ausnahmen, sondern Alltag. Für den Integrator, der die Anlage programmiert hat, war die Bedeutung klar. Für alle anderen beginnt an diesem Punkt die Handarbeit.

Dieser erste Teil der Serie «Gebäudedaten nutzbar machen» erklärt, wie eine Datenpunktbezeichnung aufgebaut sein muss, damit Menschen und Software sie gleichermassen verstehen. Wir zeigen, welche Grundlagen dafür in der Schweiz gelten, wie eine sinnvolle Struktur aussieht und warum eine einheitliche Bezeichnung die günstigste Investition in Datenqualität ist, die ein Betreiber tätigen kann.

Was ein Datenpunkt eigentlich ist

Ein Datenpunkt ist die kleinste Informationseinheit in einer Gebäudeautomationsanlage. Er repräsentiert einen Messwert, einen Sollwert, einen Betriebszustand oder einen Steuerbefehl. In BACnet-Anlagen entspricht jeder Datenpunkt einem Objekt mit einem Namen, einem Wert und weiteren Eigenschaften. In anderen Systemen heissen diese Einheiten Tags, Signale oder Variablen. Die Bezeichnung ist dabei mehr als ein technisches Label: Sie ist die Schnittstelle zwischen der physischen Anlage und der digitalen Welt.

Solange eine Anlage nur von einer einzigen Person bedient wird, die sie selbst programmiert hat, reicht ein beliebiger Name. Sobald aber mehrere Personen, Systeme oder Zeiträume ins Spiel kommen, wird die Bezeichnung zur Grundlage jeder weiteren Arbeit. Monitoring-Plattformen lesen Datenpunkte automatisch ein. Auswertungsskripte suchen nach bestimmten Mustern. Energiemanagementsysteme gruppieren Messpunkte nach Anlage oder Gebäude. All das funktioniert nur, wenn der Name eines Datenpunkts eindeutig, konsistent und maschinenlesbar ist.

In der Praxis scheitern viele Monitoring-Projekte nicht an fehlenden Daten, sondern an unlesbaren Bezeichnungen. Die Daten sind vorhanden, aber niemand weiss zuverlässig, welcher Datenpunkt welche physische Grösse an welchem Ort beschreibt. Das Ergebnis ist manuelle Nacharbeit bei jeder Auswertung, bei jedem Systemwechsel und bei jeder Erweiterung der Anlage.

Die Schweizer Grundlage: SWKI BA101-01

In der Schweiz bildet die Richtlinie SWKI BA101-01 die Grundlage für die Beschreibung von GA-Leistungen. Sie definiert unter anderem, welche Informationen zu einem Datenpunkt gehören und wie Datenpunktlisten aufgebaut sein sollen. Die Richtlinie unterscheidet zwischen verschiedenen Datenpunkttypen, beschreibt die Mindestangaben je Punkt und gibt Hinweise auf die Kennzeichnung von Anlagen und Aggregaten.

SWKI BA101-01 ist kein Bezeichnungsstandard im engeren Sinne, aber sie schafft den Rahmen, innerhalb dessen Bezeichnungskonventionen entwickelt und vereinbart werden. Wer als Bauherr oder Betreiber eine Datenpunktliste bestellt, kann sich auf diese Richtlinie stützen und verlangen, dass die gelieferten Listen den darin beschriebenen Anforderungen entsprechen. Das ist wichtig, weil ohne eine solche Grundlage jeder Integrator seine eigene Logik mitbringt und die Ergebnisse entsprechend heterogen ausfallen.

Ergänzend dazu gibt die VDI 3814 als deutschsprachige Richtlinie für Gebäudeautomation Hinweise auf die Strukturierung von Datenpunkten und deren Dokumentation. Sie ist in der Schweiz nicht normativ verbindlich, wird aber in der Praxis häufig als Referenz herangezogen, weil sie die Themen Datenpunktlisten und Funktionsbeschreibungen detaillierter behandelt als die Schweizer Normen allein.

Die KBOB-Empfehlung BACnet schliesslich konkretisiert die Anforderungen für BACnet-Anlagen in der Schweiz. Sie legt fest, welche Objektnamen und Objektbeschreibungen in BACnet-Geräten vorhanden sein müssen, und gibt Hinweise auf die Struktur von Datenpunktlisten. Wer BACnet-Anlagen plant oder betreibt, kommt an dieser Empfehlung nicht vorbei. Unser Artikel «Datenpunktlisten & Beschriftungsregeln: Die unsichtbare Grundlage des Betriebs» behandelt die BACnet-spezifischen Anforderungen im Detail.

Warum schlechte Bezeichnungen teuer sind

Die Kosten schlechter Datenpunktbezeichnungen sind selten auf einer Rechnung sichtbar. Sie verstecken sich im Aufwand für Nacharbeiten, in der Zeit, die Betreiber und Planer damit verbringen, Datenpunkte zu identifizieren und zuzuordnen, und in den Fehlern, die entstehen, wenn diese Zuordnung falsch ist.

Ein konkretes Beispiel aus der Praxis: Eine Liegenschaft mit mehreren Lüftungsanlagen soll energetisch ausgewertet werden. Die Datenpunkte sind vorhanden, aber die Namen folgen keiner einheitlichen Logik. Manche Anlagen verwenden Abkürzungen, andere ausgeschriebene Begriffe, wieder andere Nummern ohne Kontext. Um die Zulufttemperaturen aller Anlagen zu vergleichen, muss jemand die Liste manuell durcharbeiten, jeden Punkt prüfen und die Zuordnung dokumentieren. Das kostet Zeit, und diese Zeit fällt bei jeder neuen Auswertung wieder an.

Noch teurer wird es, wenn Systeme gewechselt werden. Wer eine neue Gebäudeleittechnik einführt oder eine Monitoring-Plattform integriert, muss alle Datenpunkte neu zuordnen. Ohne strukturierte Bezeichnungen ist das ein Projekt für sich. Mit einer einheitlichen Logik ist es eine weitgehend automatisierbare Aufgabe.

Dazu kommt das Risiko von Fehlern. Wenn ein Datenpunkt falsch zugeordnet wird, weil sein Name mehrdeutig ist, können Auswertungen falsche Schlüsse liefern. Im Energiemonitoring kann das dazu führen, dass Einsparmassnahmen an der falschen Anlage angesetzt werden. In der Betriebsoptimierung kann es bedeuten, dass Alarme nicht der richtigen Komponente zugeordnet werden. Die Folgekosten solcher Fehler sind schwer zu beziffern, aber sie sind real.

Der Aufbau einer strukturierten Bezeichnung

Eine strukturierte Datenpunktbezeichnung folgt einer hierarchischen Logik. Sie beschreibt, wo sich ein Datenpunkt befindet, zu welcher Anlage er gehört, welches Aggregat er betrifft und welche Funktion er hat. Diese vier Ebenen bilden das Grundgerüst, das in der Praxis bewährt ist und das auch SWKI BA101-01 und die KBOB-Empfehlung BACnet als Orientierung vorgeben.

Ebene 1: Liegenschaft

Die oberste Ebene identifiziert die Liegenschaft oder den Standort. In einem Portfolio mit mehreren Gebäuden ist diese Ebene unverzichtbar, weil sonst Datenpunkte aus verschiedenen Liegenschaften nicht unterschieden werden können. Typische Kürzel sind Standortcodes, Gebäudenummern oder Projektnummern, die der Bauherr vorgibt. Wichtig ist, dass diese Kürzel eindeutig und stabil sind, also nicht bei einer Umbenennung des Gebäudes geändert werden.

Ebene 2: Anlage

Die zweite Ebene bezeichnet die technische Anlage, zu der ein Datenpunkt gehört. Das kann eine Lüftungsanlage, eine Heizgruppe, eine Kälteanlage oder eine Beleuchtungssteuerung sein. Auch hier gilt: Die Bezeichnung muss mit der Anlagenkennzeichnung in den Plänen und der Dokumentation übereinstimmen. Wenn die Lüftungsanlage im Schema «LU-01» heisst, soll sie im Datenpunktnamen ebenfalls «LU-01» heissen, nicht «Luft1» oder «Ventilation A».

Diese Konsistenz ist entscheidend. Sie erlaubt es, alle Datenpunkte einer Anlage mit einem einfachen Filter zu finden, und sie stellt sicher, dass die digitale Welt die physische Anlage korrekt abbildet. Abweichungen zwischen Plänen und Datenpunktlisten sind eine der häufigsten Ursachen für Verwirrung im Betrieb.

Ebene 3: Aggregat

Die dritte Ebene beschreibt das Aggregat oder die Komponente innerhalb der Anlage. Das kann ein Ventilator, eine Pumpe, ein Wärmetauscher, ein Ventil oder ein Sensor sein. Auch hier ist die Übereinstimmung mit der Dokumentation wichtig. Wenn der Zuluftventilator im Schema «VEN-ZU» heisst, soll er im Datenpunktnamen entsprechend bezeichnet sein.

In grossen Anlagen mit vielen gleichartigen Komponenten braucht es zusätzlich eine Nummerierung. Zwei Umwälzpumpen in derselben Anlage müssen unterscheidbar sein, also etwa «PU-01» und «PU-02». Diese Nummerierung muss in der Dokumentation festgelegt und konsequent durchgehalten werden.

Ebene 4: Funktion

Die vierte Ebene beschreibt die Funktion des Datenpunkts: Was wird gemessen, gesteuert oder überwacht? Typische Funktionskürzel sind «T» für Temperatur, «P» für Druck, «Q» für Volumenstrom, «SP» für Sollwert, «FB» für Rückmeldung oder «CMD» für Befehl. Auch hier gilt: Die Kürzel müssen definiert und dokumentiert sein. Eine Liste der verwendeten Abkürzungen gehört zu jeder Datenpunktliste.

Zusätzlich zur Funktion kann die Einheit angegeben werden, also etwa «°C» für Celsius oder «Pa» für Pascal. In BACnet-Anlagen ist die Einheit ein eigenes Objektattribut und muss nicht zwingend im Namen stehen. In anderen Systemen kann es sinnvoll sein, die Einheit im Namen zu kodieren, um Verwechslungen zu vermeiden.

Trennzeichen, Gross- und Kleinschreibung, Sonderzeichen

Die Wahl des Trennzeichens zwischen den Ebenen ist eine technische Entscheidung, die früh getroffen werden muss. Üblich sind Unterstriche («_»), Punkte («.») oder Schrägstriche («/»). Wichtig ist, dass das gewählte Trennzeichen in allen verwendeten Systemen verarbeitet werden kann und nicht mit anderen Bedeutungen kollidiert. In manchen Systemen hat der Punkt eine besondere Bedeutung in der Adressierung, was zu Problemen führen kann.

Sonderzeichen wie Umlaute, Leerzeichen oder Klammern sollten in Datenpunktnamen grundsätzlich vermieden werden. Sie können in Schnittstellen, Datenbanken oder Skripten zu Fehlern führen, die schwer zu debuggen sind. Gross- und Kleinschreibung sollte ebenfalls einheitlich gehandhabt werden. Viele Systeme unterscheiden zwischen «Temp» und «temp», was zu doppelten oder nicht gefundenen Datenpunkten führen kann.

Diese Regeln klingen trivial, aber in der Praxis werden sie häufig nicht konsequent eingehalten. Der Grund ist meistens, dass keine verbindliche Vorgabe existiert und jeder Integrator seine eigenen Gewohnheiten mitbringt. Die Lösung ist einfach: Die Bezeichnungskonvention muss im Lastenheft stehen und Teil der Abnahmekriterien sein.

Bezeichnung und Semantik: Wo die Grenzen liegen

Eine strukturierte Datenpunktbezeichnung ist ein grosser Schritt in Richtung Datenqualität, aber sie hat Grenzen. Sie kodiert Informationen in einem lesbaren String, aber sie macht diese Informationen nicht maschineninterpretierbar im semantischen Sinne. Ein System, das den Namen «LU-01_VEN-ZU_T_ZU» liest, kann daraus ableiten, dass es sich um die Zulufttemperatur des Zuluftventilators der Lüftungsanlage LU-01 handelt, aber nur, wenn es die Konvention kennt und korrekt parst.

Semantische Modelle wie Brick Schema oder Project Haystack gehen einen Schritt weiter. Sie beschreiben nicht nur den Namen eines Datenpunkts, sondern seine Bedeutung, seine Beziehungen zu anderen Datenpunkten und seine Rolle im Gebäudesystem. Ein Datenpunkt ist dann nicht mehr nur «LU-01_VEN-ZU_T_ZU», sondern ein Objekt vom Typ «Supply Air Temperature Sensor», das zu einer «Air Handling Unit» gehört, die einem bestimmten Raum oder einer Zone dient. Diese Beschreibung ist für Software direkt nutzbar, ohne dass die Konvention bekannt sein muss.

Wir behandeln diese semantischen Modelle ausführlich in Teil 2 dieser Serie, «Brick und Haystack: Semantische Modelle für Gebäudedaten einfach erklärt». Für diesen ersten Teil ist wichtig zu verstehen: Eine gute Datenpunktbezeichnung ist die Voraussetzung für jede spätere Semantisierung. Wer heute unstrukturierte Namen verwendet, muss morgen mehr Aufwand betreiben, um diese Daten in ein semantisches Modell zu überführen.

Bezeichnung im Projektalltag verankern

Die beste Bezeichnungskonvention nützt nichts, wenn sie nicht konsequent angewendet wird. In der Praxis sehen wir drei Stellen, an denen die Konvention verankert sein muss.

Die erste Stelle ist das Lastenheft. Wer als Bauherr oder Planer eine GA-Anlage ausschreibt, muss die Bezeichnungskonvention als verbindliche Anforderung formulieren. Das schliesst die Struktur der Bezeichnung, die verwendeten Abkürzungen, die Trennzeichen und die Anforderungen an die Datenpunktliste ein. Ohne diese Vorgabe ist die Konvention nicht durchsetzbar.

Die zweite Stelle ist die Abnahme. Die Datenpunktliste muss bei der Abnahme geprüft werden, und Abweichungen von der Konvention müssen als Mängel behandelt werden. Das setzt voraus, dass die Abnahmekriterien klar definiert sind und dass jemand die Prüfung tatsächlich durchführt. In unserem Artikel «Vom Lastenheft zur Abnahme: Der BACnet-Planungsprozess in der Praxis» beschreiben wir, wie dieser Prozess strukturiert werden kann.

Die dritte Stelle ist der Betrieb. Wenn Anlagen erweitert oder geändert werden, müssen neue Datenpunkte nach derselben Konvention bezeichnet werden. Das erfordert, dass die Konvention dokumentiert und zugänglich ist, und dass Änderungsaufträge die Bezeichnungsanforderungen explizit einschliessen. Ohne diese Disziplin wächst die Heterogenität mit jeder Erweiterung.

Ein praktischer Hinweis: Die Bezeichnungskonvention sollte als eigenständiges Dokument geführt werden, das versioniert und mit der Datenpunktliste verknüpft ist. So ist jederzeit nachvollziehbar, welche Konvention zu welchem Zeitpunkt gültig war, und Änderungen können kontrolliert eingeführt werden.

Bezeichnung und BIM: Was zusammengehört

In Projekten, die mit Building Information Modelling arbeiten, stellt sich die Frage, wie Datenpunktbezeichnungen mit dem BIM-Modell verknüpft werden. Die Antwort ist grundsätzlich einfach: Die Anlagenkennzeichnung im BIM-Modell und die Anlagenkennzeichnung in der Datenpunktliste müssen übereinstimmen. Wenn eine Lüftungsanlage im IFC-Modell eine bestimmte Kennung trägt, soll diese Kennung auch in den Datenpunktnamen erscheinen.

In der Praxis ist diese Konsistenz schwerer herzustellen als es klingt. BIM-Modelle werden oft von Architekten oder Haustechnikplanern erstellt, die andere Bezeichnungslogiken verwenden als GA-Integratoren. Die Informationsanforderungen nach SN EN ISO 19650 (AIR und EIR) können helfen, diese Anforderungen frühzeitig zu koordinieren. Wer im Projekt BIM und GA zusammenbringen will, muss die Bezeichnungskonvention als gemeinsame Anforderung in beiden Welten verankern.

Wie BIM-Daten in den Betrieb überführt werden und welche Informationen der Betrieb wirklich braucht, behandeln wir in Teil 3 dieser Serie, «BIM to FM: Welche Daten der Betrieb wirklich braucht».

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel ist der Einstieg in die Serie «Gebäudedaten nutzbar machen». Die weiteren Teile bauen direkt darauf auf: Teil 2, «Brick und Haystack: Semantische Modelle für Gebäudedaten einfach erklärt», zeigt, wie strukturierte Bezeichnungen in maschinenlesbare Semantik überführt werden. Teil 3, «BIM to FM: Welche Daten der Betrieb wirklich braucht», behandelt die Verbindung zwischen Planungsdaten und Betriebsdaten. Teil 4, «Daten für Monitoring und KI: Was sauber sein muss, bevor Algorithmen helfen», erklärt, welche Datenqualität Voraussetzung für automatisierte Auswertungen ist.

Wer die BACnet-spezifischen Anforderungen an Datenpunktlisten und Beschriftungsregeln vertiefen möchte, findet diese in unserem Artikel «Datenpunktlisten & Beschriftungsregeln: Die unsichtbare Grundlage des Betriebs». Den Planungsprozess von der Ausschreibung bis zur Abnahme beschreibt «Vom Lastenheft zur Abnahme: Der BACnet-Planungsprozess in der Praxis». Was in einem GA-Lastenheft stehen muss, damit Bezeichnungsanforderungen durchsetzbar sind, zeigt «Das GA-Lastenheft: Was wirklich drinstehen muss». Und wer verstehen möchte, was schlechte GA-Dokumentation im Betrieb kostet, findet eine ehrliche Bestandsaufnahme in «Was schlechte Gebäudeautomation wirklich kostet».

Fazit

Eine strukturierte Datenpunktbezeichnung ist keine Kür, sondern die Grundlage jeder sinnvollen Datennutzung. Sie erlaubt es, Datenpunkte automatisch zuzuordnen, Auswertungen zu automatisieren und Systeme ohne manuelle Nacharbeit zu integrieren. Die Investition dafür ist gering: eine klare Konvention, verankert im Lastenheft, geprüft bei der Abnahme und durchgehalten im Betrieb.

Die Grundlagen dafür sind in der Schweiz vorhanden. SWKI BA101-01 beschreibt die Anforderungen an Datenpunktlisten, die KBOB-Empfehlung BACnet konkretisiert sie für BACnet-Anlagen, und die VDI 3814 liefert ergänzende Hinweise. Was fehlt, ist in vielen Projekten nicht das Wissen, sondern die Konsequenz in der Umsetzung.

Wer heute in eine saubere Bezeichnungskonvention investiert, spart morgen bei jedem Monitoring-Projekt, bei jedem Systemwechsel und bei jeder Erweiterung der Anlage. Das ist die günstigste Investition in Datenqualität, die ein Betreiber tätigen kann.

Sie haben Fragen dazu?

Sie möchten wissen, ob die Datenpunktbezeichnungen in Ihrer Anlage einer strukturierten Konvention folgen, oder Sie planen ein neues Projekt und wollen die Anforderungen von Anfang an richtig formulieren? Wir unterstützen Sie dabei, von der Konventionsdefinition bis zur Prüfung der Datenpunktliste. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• SWKI BA101-01: Gebäudeautomation, Leistungen und Grundlagen, Schweizerischer Verein von Gebäudetechnik-Ingenieuren (aktuelle Ausgabe)
• VDI 3814: Gebäudeautomation, Verein Deutscher Ingenieure, insbesondere Blätter zu Datenpunktlisten und Funktionsbeschreibungen
• KBOB Empfehlung BACnet Anwendung, Version 2.0, Juli 2021, inkl. Leitfaden (Anforderungen an Objektnamen, Datenpunktlisten und Anlagenkennzeichnung)
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet, Objektnamen und Objekteigenschaften
• SN EN ISO 19650 (Teile 1 und 2): Organisation und Digitalisierung von Informationen zu Bauwerken und Ingenieurleistungen, einschliesslich Informationsmanagement mit BIM (AIR, EIR)
• SIA 2051: Building Information Modelling (BIM), Grundlagen zur Anwendung der BIM-Methode, Merkblatt SIA 2051
• Eigene Projekterfahrung der WENGET GmbH aus GA-Planung, BACnet-Analysen, Datenpunktprüfungen und Betriebsbegleitung