BACnet, KNX, Modbus… alles vernetzt, alles verfügbar.
Aber heißt das automatisch „gemeinsamer Datenpunkt"?
Nein. Und genau hier entstehen in der Praxis die größten Missverständnisse – mit echten Folgen für Planung, Ausschreibung und Budget.
Heute machen wir das ein für alle Mal sauber.
❌ Das Problem in der Praxis
Viele setzen gleich:
👉 „Wenn es über Kommunikation kommt → ist es gemeinsam."
Das klingt logisch – ist aber fachlich falsch.
Die Folgen:
- falsche Planung
- unklare Ausschreibung
- Diskussionen in der Ausführung
- unnötige Kosten 💸
Damit räumen wir jetzt auf.
📖 Die zwei Definitionen – wasserfest
Die VDI 3814 trennt zwischen Ein-/Ausgabefunktionen (Kapitel 7.3.1.1) und Wertefunktionen (Kapitel 7.3.1.2). Daraus ergeben sich zwei klare Definitionen:
Physikalischer Datenpunkt
Ein Datenpunkt, der im eigenen GA-System primär physikalisch erfasst und projektiert wird. Die Anbindung kann über klassische I/O-Verdrahtung oder über ein Datenkommunikationsprotokoll (KNX, BACnet, M-Bus, Modbus etc.) erfolgen. Entscheidend ist nicht der Übertragungsweg, sondern dass der Datenpunkt im eigenen System geplant, parametriert und in Betrieb genommen wird.
Gemeinsamer Datenpunkt
Ein Wert, der zwischen zwei Automationseinrichtungen ausgetauscht wird und im Quellsystem bereits als eigenständiges, fertig projektiertes Werteobjekt existiert. Das empfangende System übernimmt den Wert über eine definierte Schnittstelle – es projektiert das zugehörige Feldgerät nicht selbst. Die Verantwortungsabgrenzung erfolgt vertraglich (VOB/C, Nebenleistungen).
Merke dir:
- Physikalisch = Du erfasst und projektierst es selbst.
- Gemeinsam = Du übernimmst es aus einem fremden System, das bereits fertig ist.
🛠️ Was bedeutet „projektieren" konkret?
Die VDI 3814 macht in Kapitel 7.3 deutlich: Ein-/Ausgabefunktionen umfassen nicht nur das Anschließen eines Geräts. Sie umfassen die komplette Projektierungsarbeit:
- Vorgabe und Einstellung von Kennlinien (z. B. Sensorlinearisierung)
- Vorgabe von Bereichen (Messbereiche, Skalierungen)
- Vergabe der zugehörigen SI-Einheiten (°C, kWh, m³/h, …)
- Generierung und Zuordnung eindeutiger Zustands- und Statustexte (z. B. „Pumpe läuft" / „Pumpe Störung")
- Verwendung und funktionsspezifische Zuordnung weiterer Eigenschaften, passend zum gewählten Datenkommunikationsprotokoll
- Vergabe der Benutzeradressen im Kennzeichnungssystem (BAS)
👉 Die Faustregel:
- Wenn du diese Arbeit leistest → physikalischer Datenpunkt
- Wenn das Quellsystem bereits fertig projektiert ist und du den Wert nur übernimmst → gemeinsamer Datenpunkt
So einfach ist die Grenze – und so klar lässt sie sich in jedem Projekt prüfen.
⚙️ Kurzer Einschub: Was heißt eigentlich „kommunikativ"?
Die VDI 3814 unterscheidet bei Ein-/Ausgabefunktionen die Verbindung zur physikalischen Welt oder zu kommunikativen Systemen.
„Kommunikativ" beschreibt damit den Übertragungsweg – nicht die Art des Datenpunkts.
Ein Datenpunkt kann kommunikativ angebunden und trotzdem physikalisch sein. Genau hier passiert der Denkfehler.
🧠 Der entscheidende Unterschied auf einen Blick
| Frage | Physikalisch | Gemeinsam |
|---|---|---|
| Wer plant das Feldgerät? | Du (GA-Gewerk) | Anderes Gewerk / System |
| Wer parametriert es? | Du | Anderer Lieferant |
| Wer programmiert es? | Du | Anderer Lieferant |
| Wer nimmt es in Betrieb? | Du | Anderer Lieferant |
| Wo liegt die Verantwortung? | Bei dir | Beim Quellsystem |
| Was steht in deiner GA-FL? | BI / BO / AI / AO | AV / BV (Werteobjekt) |
Die VDI unterscheidet nicht nach Protokoll, Netzwerk oder „liegt irgendwo im System". Sondern nach Herkunft, Verantwortung und Projektierungsaufwand.
🔧 Zwei Praxisfälle mit KNX – der Beweis
Das gleiche Protokoll. Zwei völlig verschiedene Klassifizierungen. Der Unterschied liegt nicht im Bus – sondern in der Verantwortung.
🟢 Fall A: KNX als Teil deines eigenen GA-Systems → physikalisch
Szenario:
Du planst und realisierst die GA für ein Bürogebäude. Dazu gehören KNX-Taster, Präsenzmelder, Jalousieaktoren, Dimmaktoren – alles auf KNX-TP.
Wer macht die Projektierungsarbeit?
| Projektierungsaufgabe | Wer? |
|---|---|
| Kennlinien / Bereiche | Du |
| SI-Einheiten | Du |
| Status- und Zustandstexte | Du |
| Funktionsspezifische Eigenschaften | Du |
| Benutzeradresse (BAS) | Du |
| Inbetriebnahme & Dokumentation | Du |
Ergebnis:
- Klassifizierung: physikalisch
- In der GA-FL: BI / BO / AI / AO
- Integrationsspalte: KNX-TP
Warum?
Du leistest die komplette Projektierungsarbeit. Das KNX-Protokoll ist nur der Übertragungsweg – nicht das Klassifizierungskriterium.
🔵 Fall B: KNX wurde von Dritten geliefert → gemeinsam
Szenario:
Ein Elektrogewerk oder ein externer KNX-Integrator hat bereits eine komplette KNX-Anlage geplant, parametriert, programmiert und in Betrieb genommen. Die Anlage läuft autark. Du brauchst aus dieser Anlage nur bestimmte Werte in deiner GA – z. B. Präsenz-Status für die Lüftung, Helligkeitswerte für die Beschattungslogik oder Verbrauchszähler für das Energiemonitoring.
Wer macht die Projektierungsarbeit?
| Projektierungsaufgabe | Wer? |
|---|---|
| Kennlinien / Bereiche | Fremdgewerk |
| SI-Einheiten | Fremdgewerk |
| Status- und Zustandstexte | Fremdgewerk |
| Funktionsspezifische Eigenschaften | Fremdgewerk |
| Benutzeradresse (BAS) | Fremdgewerk |
| Inbetriebnahme der KNX-Anlage | Fremdgewerk |
| Werteempfang in der GA | Du |
Ergebnis:
- Klassifizierung: gemeinsam
- In der GA-FL: AV / BV (Werteobjekt)
- Eintrag: Verweis auf Quellsystem / Schnittstelle
Warum?
Die komplette Projektierung ist fremdverantwortet. Du nutzt nur das Ergebnis. Genau deshalb verweist die VDI auf VOB/C – die Abgrenzung gehört vertraglich geregelt.
🎯 Beweisstück: Die VDI zeigt es selbst
Wirf einen Blick in die Beispiel-GA-Funktionsliste der VDI 3814 zur KNX-Integration im GA-System.
Was steht dort?
- KNX-Taster „Beleuchtung EIN" → eingetragen als Binäre Eingabe (BI)
- KNX-Taster „Jalousie AUF" → eingetragen als Binäre Eingabe (BI)
- Spalte „Integration" trägt den Vermerk KNX-TP
Die VDI selbst klassifiziert KNX-angebundene Geräte als physikalische Ein-/Ausgabefunktionen – nicht als gemeinsame Datenpunkte.
Warum? Weil der GA-Integrator das Gerät einbindet und projektiert. Das Protokoll ist nur das Medium.
🧪 Häufige Zweifel – ausgeräumt
„Aber der Wert kommt doch über KNX – das ist Kommunikation, also gemeinsam!"
→ Falsch. Kommunikation ist der Übertragungsweg. Entscheidend ist, wer das Feldgerät plant und projektiert. Vgl. VDI 3814 Kapitel 7.3.1.1.
„Aber ich empfange den Wert in meinem System – also habe ich doch Verantwortung."
→ Empfangen ≠ projektieren. Bei einem gemeinsamen Datenpunkt projektierst du nur den Werteempfang, nicht das Quellgerät.
„Was ist mit dem Gateway selbst – physikalisch oder gemeinsam?"
→ Das Gateway ist ein Werkzeug zur Wertübergabe. Es ändert nichts an der Klassifizierung der übertragenen Werte. Die Werte bleiben gemeinsam, wenn das Quellsystem sie bereits projektiert bereitstellt.
„Und wenn ich das Fremdsystem später mitbetreue?"
→ Dann verschiebt sich die vertragliche Verantwortung – und damit ggf. die Klassifizierung. Genau deshalb verweist die VDI auf VOB/C: Die Abgrenzung muss vertraglich klar sein.
„Was, wenn das Gerät zwar von mir kommt, aber vom Hersteller vorparametriert ist?"
→ Solange du das Gerät in deine GA integrierst, projektierst und verantwortest – bleibt es physikalisch. Werkseinstellungen ändern daran nichts.
⚠️ Der kritische Praxisfehler
Ein typisches Missverständnis:
👉 „Das Ventil hängt doch auf BACnet → also gemeinsamer Datenpunkt."
Realität:
- Wird das Gerät vom GA-Gewerk integriert → physikalischer Datenpunkt
- Wird der Wert aus einem fremdverantworteten System übernommen → gemeinsamer Datenpunkt
Es hängt nicht am Bus, sondern an dieser einen Frage: Wer integriert und verantwortet das Gerät?
💡 Warum das so wichtig ist
Wenn diese Unterscheidung nicht sauber gemacht wird, entstehen genau diese Probleme:
- „Brauchen wir ein I/O-Modul oder nicht?"
- „Wer integriert das Gerät?"
- „Ist das im Leistungsumfang enthalten?"
Und plötzlich: Nachträge, Zeitverzug, Diskussionen.
⚖️ Ehrliche Bewertung
Positiv 👍
- klare Struktur durch die VDI
- saubere Trennung möglich
- bessere Ausschreibungen, weniger Streit
Negativ ⚠️
- schwer verständlich beim ersten Lesen
- häufig falsch interpretiert
- alte Denkweisen halten sich hartnäckig
🔥 Der wichtigste Merksatz
Nicht das Protokoll entscheidet – sondern die Verantwortung.
🎯 Fazit
- Kommunikation ≠ gemeinsamer Datenpunkt
- Auch BACnet, KNX oder M-Bus können physikalisch sein
- Entscheidend ist: Wer baut, projektiert und verantwortet den Datenpunkt?
- Die Abgrenzung gehört vertraglich (VOB/C) sauber geregelt
Wer das sauber trennt, spart Zeit, Geld und Diskussionen.
Solche Fehler ab heute vermeiden
Drei Tools in der GA-Coach App, die genau dabei helfen –
direkt anwendbar in deinem nächsten Projekt.
|
🎯
|
VDI-Datenpunkt-Assistent Klassifiziere Datenpunkte korrekt nach VDI 3814 – und vermeide genau die Fehler aus diesem Beitrag. |
› |
|
📚
|
VDI-Lernmodule Verstehe Schritt für Schritt, was hinter den Automationsfunktionen wirklich steckt. |
› |
|
📋
|
Leistungsphasen-Tool Prüfe Grund- und Besondere Leistungen über alle Leistungsphasen hinweg. |
› |
gacoach.app · Dein Trainings-Tool für die Gebäudeautomation
❓ Wie gehst du aktuell mit dieser Unterscheidung um?
Schreib mir deine Erfahrung oder deine größte Herausforderung in die Kommentare. Ich greife regelmäßig Praxis-Themen aus der Community auf 💪
Viele Grüße
Dennis
Der GA-Coach
