Wer mappt was? Schnittstellenliste und Verantwortung

Wer die vorangegangenen fünf Teile dieser Serie gelesen hat, kennt die technischen Eigenheiten jeder Schnittstelle: DALI für die Beleuchtung, EnOcean für Funk, Modbus für Zähler und Geräte, BACnet für die Gebäudeleittechnik, MQTT für Dashboards und Cloud. Jede dieser Schnittstellen hat ihre eigene Logik, ihre eigenen Datenpunkte und ihre eigenen Fehlerquellen. Was die fünf Teile aber bewusst offengelassen haben, ist die Frage, die in der Praxis am häufigsten zu Problemen führt: Wer ist eigentlich zuständig? Wer plant die Schnittstelle, wer liefert sie, wer parametriert sie, und wer prüft, ob sie funktioniert?

Dieser sechste und letzte Teil der Serie ist eine Synthese. Wir zeigen, warum die meisten Integrationsprobleme keine technischen Probleme sind, sondern Organisationsprobleme. Und wir beschreiben, wie eine Schnittstellenliste mit klarer Verantwortung pro Datenpunkt und ein gemeinsamer Integrationstest die Lücken zwischen den Gewerken schliessen.

Warum Schnittstellenprobleme fast immer Organisationsprobleme sind

In unserer Projekterfahrung entstehen die meisten Integrationsprobleme nicht, weil ein Protokoll technisch versagt. Sie entstehen, weil zwei Unternehmer davon ausgegangen sind, dass der jeweils andere die Schnittstelle liefert. Oder weil niemand definiert hat, in welchem Format ein Datenpunkt übergeben wird. Oder weil die Parametrierung zwar ausgeführt wurde, aber niemand sie geprüft hat.

Das Muster ist immer ähnlich: Ein KNX-Installateur liefert die Busanlage. Ein Lüftungslieferant liefert das Gerät mit Modbus-Schnittstelle. Ein GA-Unternehmer liefert den KNX-Modbus-Gateway. Aber wer definiert die Modbus-Register? Wer stellt sicher, dass die Registeradressen im Gateway mit den Registeradressen im Lüftungsgerät übereinstimmen? Wer prüft, ob der Istwert der Zulufttemperatur tatsächlich auf der richtigen Gruppenadresse im KNX-Bus erscheint? Wenn diese Fragen nicht vor der Ausführung schriftlich beantwortet sind, werden sie auf der Baustelle beantwortet, meistens unter Zeitdruck und auf Kosten der Qualität.

Dasselbe gilt für die Schnittstelle zwischen KNX und BACnet: Wer legt fest, welche KNX-Gruppenadressen als BACnet-Objekte exportiert werden? Wer definiert die Objektnamen nach den Vorgaben der Bauherrschaft? Wer prüft, ob die Werte auf der Managementebene korrekt ankommen und richtig skaliert sind? Und bei MQTT: Wer definiert die Topic-Struktur, wer konfiguriert den Broker, wer stellt sicher, dass die Daten im richtigen Intervall und im richtigen Format geliefert werden?

Die Antwort auf all diese Fragen gehört nicht in die Ausführungsphase. Sie gehört in die Planung, und zwar in ein Dokument, das alle Beteiligten kennen und das verbindlich ist: die Schnittstellenliste.

Was eine Schnittstellenliste leisten muss

Eine Schnittstellenliste ist kein Protokollhandbuch und keine Gerätebeschreibung. Sie ist ein Organisationsdokument. Sie hält für jede Schnittstelle und jeden relevanten Datenpunkt fest, wer was liefert, wer was parametriert und wer was prüft. Sie ist das Bindeglied zwischen dem Lastenheft des Bauherrn und den Werkverträgen der Unternehmer.

Eine vollständige Schnittstellenliste enthält mindestens die folgenden Angaben pro Datenpunkt oder Datenpunktgruppe:

Die Bezeichnung des Datenpunkts, eindeutig und konsistent mit der Datenpunktliste der GA-Planung. Den Schnittstellentyp, also KNX intern, KNX-DALI, KNX-EnOcean, KNX-Modbus, KNX-BACnet oder KNX-MQTT. Das Protokoll auf beiden Seiten der Schnittstelle. Den Datenpunkttyp auf der KNX-Seite, also den DPT. Den entsprechenden Wert auf der Gegenseite, also die Modbus-Registeradresse, den BACnet-Objekttyp und die Objektinstanz, den MQTT-Topic oder die DALI-Geräteadresse. Die Skalierung und Einheit, falls eine Umrechnung nötig ist. Den Unternehmer, der die Schnittstelle liefert. Den Unternehmer, der die Schnittstelle parametriert. Den Unternehmer, der die Schnittstelle im Integrationstest prüft. Den Verweis auf das Prüfprotokoll.

Diese Liste klingt aufwendig. In der Praxis ist sie es nicht, wenn sie früh genug erstellt wird. Wer sie erst nach der Vergabe erstellt, kämpft gegen bereits festgelegte Werkverträge. Wer sie vor der Ausschreibung erstellt, kann die Verantwortlichkeiten direkt in die Leistungsbeschreibungen einarbeiten.

Die Schnittstellenmatrix: Verantwortung auf einen Blick

Eine bewährte Form, die Schnittstellenliste zu strukturieren, ist die Schnittstellenmatrix. Sie stellt die Schnittstellen in den Zeilen dar und die Verantwortlichkeiten in den Spalten. Für jede Kombination aus Schnittstelle und Verantwortung wird eingetragen, wer die Hauptverantwortung trägt (H), wer mitwirkt (M) und wer informiert wird (I). Dieses Prinzip ist aus dem Projektmanagement bekannt und funktioniert auch in der GA-Planung.

Die folgende Tabelle zeigt ein vereinfachtes Beispiel für ein Projekt mit KNX als Feldbus und BACnet als Managementebene. Die Spalten stehen für die typischen Rollen in einem solchen Projekt.

Diese Tabelle ist ein Beispiel und kein Universalrezept. Die Verantwortlichkeiten hängen vom konkreten Projekt, von den Werkverträgen und von der Kompetenz der Beteiligten ab. Entscheidend ist, dass die Matrix existiert, dass sie von allen Beteiligten anerkannt wird und dass sie bei Änderungen aktualisiert wird.

Schnittstelle für Schnittstelle: Was die Verantwortung konkret bedeutet

KNX und DALI

Bei der Schnittstelle zwischen KNX und DALI liegt die Planung des Mappings beim GA-Planer. Er legt fest, welche DALI-Gruppen und Szenen auf welche KNX-Gruppenadressen abgebildet werden. Der KNX-Installateur kennt die Busleitungen und die physikalischen Adressen. Der GA-Unternehmer, der den KNX-DALI-Gateway liefert, parametriert das Mapping in der ETS und im DALI-Konfigurationswerkzeug. Im Integrationstest prüft die Fachbauleitung gemeinsam mit dem GA-Unternehmer, ob jede Leuchtengruppe auf den richtigen Schaltbefehl reagiert, ob die Dimmkurven stimmen und ob Szenen korrekt ausgelöst werden. Mehr zu den technischen Grundlagen dieser Schnittstelle findet sich in Teil 1 der Serie, «KNX und DALI: Beleuchtung sauber koppeln».

KNX und EnOcean

Bei EnOcean ist die Verantwortung für die Inbetriebnahme besonders klar zu regeln, weil die Anlernprozedur gerätespezifisch ist und oft auf der Baustelle durchgeführt wird. Der GA-Planer legt fest, welche EnOcean-Sensoren auf welche KNX-Gruppenadressen abgebildet werden. Der GA-Unternehmer, der den KNX-EnOcean-Gateway liefert, führt das Anlernen durch und parametriert die Zuordnung in der ETS. Im Integrationstest wird geprüft, ob jeder Sensor das richtige Telegramm auf der richtigen Gruppenadresse auslöst. Besonderes Augenmerk gilt der Reichweite und der Signalqualität, die auf der Baustelle anders sein kann als im Planungsstadium. Die technischen Grundlagen beschreibt Teil 2 der Serie, «KNX und EnOcean: Funk für Sanierung und flexible Räume».

KNX und Modbus

Die Modbus-Schnittstelle ist die fehleranfälligste, weil sie zwei Welten verbindet, die unterschiedliche Sprachen sprechen. Der GA-Planer erstellt die Registerliste auf Basis der Gerätedokumentation des Lieferanten. Der Lieferant des Feldgeräts, also etwa der Lüftungsanlage oder der Wärmepumpe, muss die Registerliste bestätigen und bei Abweichungen korrigieren. Der GA-Unternehmer parametriert den Gateway auf Basis der bestätigten Registerliste. Im Integrationstest wird für jeden Datenpunkt geprüft, ob der Wert im KNX-Bus mit dem Wert im Feldgerät übereinstimmt und ob Schreibbefehle korrekt ausgeführt werden. Ohne bestätigte Registerliste vom Lieferanten ist dieser Test nicht durchführbar. Das ist ein häufiger Grund für Verzögerungen bei der Inbetriebnahme. Die technischen Hintergründe behandelt Teil 3 der Serie, «KNX und Modbus: Zähler, Wärmepumpen und Lüftungsgeräte einbinden».

KNX und BACnet

Bei der Schnittstelle zwischen KNX und BACnet kommen zwei normierte Welten zusammen, was die Planung erleichtert, aber die Verantwortung nicht aufhebt. Der GA-Planer definiert die Objektliste: Welche KNX-Gruppenadressen werden als BACnet-Objekte exportiert, mit welchem Objekttyp, welcher Instanznummer und welchem Objektnamen? Die Namenskonvention muss mit den Vorgaben der Bauherrschaft für die Managementebene übereinstimmen. Der GA-Unternehmer parametriert den KNX-BACnet-Gateway und stellt sicher, dass die Objekte auf der Managementebene sichtbar sind. Im Integrationstest prüft die Fachbauleitung, ob alle Objekte vorhanden sind, ob die Werte korrekt skaliert sind und ob Schreibbefehle von der Managementebene in den KNX-Bus durchkommen. Die KBOB-Empfehlung BACnet gibt Hinweise zur Benennung und Strukturierung von BACnet-Objekten, die auch bei dieser Schnittstelle relevant sind. Die technischen Grundlagen beschreibt Teil 4 der Serie, «KNX und BACnet: Raumautomation an die Gebäudeleittechnik».

KNX und MQTT

MQTT ist die jüngste Schnittstelle in dieser Serie und die mit dem grössten Gestaltungsspielraum. Der GA-Planer definiert die Topic-Struktur und das Datenformat. Der GA-Unternehmer konfiguriert den MQTT-Broker oder den Gateway und stellt sicher, dass die Daten im richtigen Intervall publiziert werden. Im Integrationstest wird geprüft, ob alle Topics vorhanden sind, ob die Werte korrekt sind und ob die Daten im Dashboard oder in der Cloud korrekt dargestellt werden. Weil MQTT oft in Richtung IT-Infrastruktur geht, ist die Abstimmung mit der IT-Abteilung oder dem Cloud-Anbieter frühzeitig zu klären. Die technischen Grundlagen beschreibt Teil 5 der Serie, «KNX und MQTT: Gebäudedaten für Dashboards und Cloud».

Wer trägt die Fachbauleitung, und was ist ihre Rolle?

Die Fachbauleitung für Gebäudeautomation ist nicht der Unternehmer, der die Schnittstellen liefert. Sie ist die unabhängige Stelle, die im Auftrag der Bauherrschaft prüft, ob die Leistungen der Unternehmer den Anforderungen des Lastenhefts entsprechen. Diese Trennung ist entscheidend.

Die Fachbauleitung prüft die Schnittstellenliste auf Vollständigkeit und Konsistenz. Sie stellt sicher, dass alle Datenpunkte aus dem Lastenheft in der Liste abgebildet sind. Sie koordiniert den Integrationstest und protokolliert die Ergebnisse. Sie entscheidet, ob eine Schnittstelle abgenommen werden kann oder ob Nachbesserungen nötig sind. Und sie stellt sicher, dass die Dokumentation, also die parametrierten Gateways, die Registerlisten, die Objektlisten und die Prüfprotokolle, vollständig an die Bauherrschaft übergeben wird.

Die SIA 108 regelt die Leistungen und Honorare der Planer, darunter auch die Fachbauleitung. Die SIA 112 beschreibt die Leistungsphasen, in denen die Fachbauleitung tätig ist. Die SIA 2046 gibt Hinweise zur Funktionskontrolle und zum Integrationstest in der Gebäudetechnik. Diese Grundlagen gelten auch für KNX-Projekte mit komplexen Schnittstellen.

Für die übergeordnete Organisation im Projekt, also die Frage, wie Bauherrschaft, Planer, Unternehmer und Fachbauleitung zusammenarbeiten, verweisen wir auf unsere Beiträge aus der Leistungsgruppe Funktionskontrollen und Integrationstests, insbesondere auf «Integrationstests in der GA: Was muss getestet werden und wer trägt die Verantwortung?» und «GA-Abnahme: Was Bauherren und Betreiber von Ausführenden einfordern müssen».

Der Integrationstest: Wie er aufgebaut sein muss

Ein Integrationstest ist kein Rundgang mit Stichproben. Er ist ein strukturierter Prüfablauf, der für jeden Datenpunkt in der Schnittstellenliste einen definierten Prüfschritt enthält. Wir empfehlen, den Integrationstest in drei Stufen aufzubauen.

Die erste Stufe ist der Gerätetest. Jedes Feldgerät wird einzeln geprüft: Kommuniziert es auf dem Bus? Liefert es die erwarteten Werte? Reagiert es auf Schreibbefehle? Dieser Test liegt in der Verantwortung des jeweiligen Unternehmers.

Die zweite Stufe ist der Schnittstellentest. Jede Schnittstelle wird Ende-zu-Ende geprüft: Kommt der Wert vom Feldgerät korrekt auf der KNX-Gruppenadresse an? Kommt der Wert von der KNX-Gruppenadresse korrekt auf der Managementebene oder im Dashboard an? Dieser Test wird gemeinsam von den beteiligten Unternehmern und der Fachbauleitung durchgeführt.

Die dritte Stufe ist der Funktionstest. Zusammengesetzte Funktionen werden geprüft: Löst ein Präsenzmelder die richtige Beleuchtungsszene aus? Regelt die Lüftungsanlage auf den Sollwert, der von der Managementebene vorgegeben wird? Werden Alarme korrekt weitergeleitet? Dieser Test liegt in der Verantwortung der Fachbauleitung und wird mit dem Bauherrn abgenommen.

Jeder Prüfschritt wird protokolliert, mit Datum, Prüfer, Ergebnis und allfälligen Mängeln. Mängel werden in einer Mängelliste erfasst und nachverfolgt. Erst wenn alle Mängel behoben sind, gilt die Schnittstelle als abgenommen. Mehr zu den Grundlagen der Funktionskontrolle und Abnahme findet sich in unseren Beiträgen «Funktionskontrolle vs. Inbetriebnahme: Ein Unterschied, der teuer werden kann» und «SIA 2046 in der Praxis: Integrale Tests Schritt für Schritt».

Was in der Ausschreibung stehen muss

Eine Schnittstellenliste nützt nichts, wenn sie nicht in die Ausschreibung einfliesst. Wir sehen in der Praxis häufig Ausschreibungen, die die Schnittstellen zwar erwähnen, aber die Verantwortung offenlassen. Der Unternehmer preist dann das Gerät ein, aber nicht die Parametrierung der Schnittstelle. Oder er preist die Parametrierung ein, aber nicht den Integrationstest. Das führt zu Nachtragsangeboten, die vermeidbar wären.

Eine vollständige Leistungsbeschreibung für eine Schnittstelle enthält: die Lieferung des Gateways oder der Schnittstellen-Hardware, die Parametrierung auf Basis der vom Planer gelieferten Datenpunktliste, die Teilnahme am Integrationstest, die Behebung von Mängeln aus dem Integrationstest und die Lieferung der vollständigen Parametrierdaten und Dokumentation an die Bauherrschaft.

Für KNX-spezifische Anforderungen an die Ausschreibung verweisen wir auf unseren Einzelbeitrag «Die häufigsten Fehler in KNX-Ausschreibungen», der diese Punkte aus der Perspektive der Ausschreibung vertieft.

Dokumentation als Teil der Leistung

Die Schnittstellenliste und die Prüfprotokolle sind nicht nur Arbeitsdokumente für die Bauphase. Sie sind Teil der Dokumentation, die der Bauherrschaft übergeben wird und die im Betrieb gebraucht wird. Wenn ein Gateway nach fünf Jahren ersetzt werden muss, braucht der Betreiber die Registerliste, die Objektliste und die Parametrierdaten. Wenn eine Schnittstelle im Betrieb Probleme macht, braucht der Servicetechniker die Prüfprotokolle aus der Inbetriebnahme.

Diese Dokumente müssen deshalb in einem Format vorliegen, das unabhängig von einem bestimmten Unternehmer nutzbar ist. Proprietäre Formate, die nur mit der Software des Lieferanten geöffnet werden können, sind für den Betrieb ungeeignet. Offene Formate, also PDF für Protokolle, Excel oder CSV für Listen und das ETS-Projektarchiv für KNX, sind die Grundlage für einen herstellerunabhängigen Betrieb.

Für das ETS-Projekt als Eigentum der Bauherrschaft verweisen wir auf den Beitrag «Das ETS-Projekt gehört dem Bauherrn» aus der Serie «KNX richtig planen».

Der rote Faden zu unseren Fachbeiträgen

Dieser Beitrag schliesst die Serie «Schnittstellen rund um KNX» ab. Die technischen Grundlagen der einzelnen Schnittstellen finden sich in den vorangegangenen Teilen: «KNX und DALI: Beleuchtung sauber koppeln» (Teil 1), «KNX und EnOcean: Funk für Sanierung und flexible Räume» (Teil 2), «KNX und Modbus: Zähler, Wärmepumpen und Lüftungsgeräte einbinden» (Teil 3), «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» (Teil 4) und «KNX und MQTT: Gebäudedaten für Dashboards und Cloud» (Teil 5).

Für die Planung einer KNX-Anlage als Ganzes empfehlen wir die Serie «KNX richtig planen», insbesondere «Topologie, Linien und IP-Backbone sauber aufbauen» (Teil 2) und «Gruppenadressen und Namenskonvention als Fundament» (Teil 3), da eine saubere Struktur die Grundlage für jede Schnittstellenplanung ist.

Für die Inbetriebnahme und Abnahme verweisen wir auf «Inbetriebnahme und Abnahme einer KNX-Anlage» (Teil 1 der Serie «KNX in Betrieb und Bestand»). Für die übergeordnete Frage der Funktionskontrollen und Integrationstests sind die Beiträge «Integrationstests in der GA: Was muss getestet werden und wer trägt die Verantwortung?», «GA-Abnahme: Was Bauherren und Betreiber von Ausführenden einfordern müssen» und «SIA 2046 in der Praxis: Integrale Tests Schritt für Schritt» aus unserer Leistungsgruppe Funktionskontrollen und Integrationstests weiterführend.

Wer sich für die Ausschreibung von KNX-Anlagen interessiert, findet in «Die häufigsten Fehler in KNX-Ausschreibungen» und in «Was KNX über den Lebenszyklus wirklich kostet» weitere Grundlagen. Für die Frage, ob KNX das richtige System ist, empfehlen wir «KNX im Zweckbau: wann es passt und wann nicht» (Teil 1 der Serie «KNX richtig planen») und «Offener Standard oder Herstellersystem? Kriterien für Bauherren».

Fazit

Die meisten Integrationsprobleme bei KNX-Projekten sind keine technischen Probleme. Sie sind Organisationsprobleme, die entstehen, weil Verantwortlichkeiten nicht klar geregelt sind. Eine Schnittstellenliste mit klarer Zuständigkeit pro Datenpunkt, eine Schnittstellenmatrix, die Planung, Lieferung, Parametrierung und Prüfung trennt, und ein strukturierter Integrationstest in drei Stufen sind die Mittel, mit denen diese Probleme verhindert werden.

Diese Mittel sind kein Mehraufwand. Sie sind die Grundlage dafür, dass eine Anlage bei der Abnahme funktioniert, dass die Dokumentation vollständig ist und dass der Betreiber im Betrieb nicht auf das Wissen eines einzelnen Unternehmers angewiesen ist. Wer die Schnittstellenliste als Planungsleistung begreift und nicht als Beilagedokument, spart Zeit und Kosten bei der Inbetriebnahme und schafft die Voraussetzung für einen herstellerunabhängigen Betrieb über den gesamten Lebenszyklus.

Sie haben Fragen dazu?

Sie planen ein KNX-Projekt mit mehreren Schnittstellen und möchten wissen, wie Sie die Verantwortlichkeiten sauber regeln? Oder Sie stehen vor einer Abnahme und stellen fest, dass die Schnittstellendokumentation lückenhaft ist? Wir unterstützen Sie bei der Erstellung der Schnittstellenliste, bei der Fachbauleitung und beim Integrationstest. Nehmen Sie mit uns Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• SIA 108: Ordnung für Leistungen und Honorare der Ingenieure und Architekten (Leistungsphasen und Fachbauleitung)
• SIA 112: Modell Bauplanung (Leistungsphasen im Bauprojekt)
• SIA 2046: Funktionale Qualitätssicherung von Gebäudetechnik-Anlagen (Funktionskontrolle und Integrationstest)
• KBOB Empfehlung BACnet Anwendung, Version 2.0, Juli 2021 (Benennung und Strukturierung von BACnet-Objekten, Projektorganisation)
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet
• EN 50090 / ISO/IEC 14543-3: KNX-Standard; KNX und ETS sind eingetragene Marken der KNX Association, Brüssel
• IEC 62386 (DALI-2): Digitales adressierbares Beleuchtungssteuerungssystem
• ISO/IEC 14543-3-10: EnOcean-Standard für energieautarke Funksensoren
• OASIS-Standard MQTT / ISO/IEC 20922: Message Queuing Telemetry Transport
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, GA-Engineering und Schnittstellenintegration