Ein IBMS wird oft als „eine Plattform, die alles verbindet“ beschrieben. Diese Beschreibung ist zutreffend und nutzlos. Die nützliche Frage ist, wo die Verbindung stattfindet, wer die Daten besitzt und was passiert, wenn ein Teilsystem sich fehlerhaft verhält.
Wir verwenden in jedem Projekt ein Drei-Schichten-Modell: Gerät, Supervision und Anwendung. Es stammt aus dem verteilten Integrationsmodell, auf dem die Projektspezifikation dieser Praxis basiert, und hat den Kontakt mit realen Gebäuden überstanden, weil es Verantwortlichkeiten explizit hält.
Warum flach besser ist als tief
Jedes zusätzliche Gateway, jeder Protokollübersetzer und jeder Middleware-Hop erhöht die Latenz, schafft einen Ausfallpunkt und eine Stelle, an der das Datenmodell abweichen kann. Eine flache Architektur reduziert die Zahl der Übersetzungen zwischen einem Sensor und der Person, die darauf reagieren muss.
Flach bedeutet nicht „keine Hierarchie“. Es bedeutet, dass die Hierarchie funktional und nicht zufällig ist: Controller am Rand, ein Supervisionskern und Anwendungen, die aus diesem Kern lesen, statt eigene Schattendatenbanken aufzubauen.
Schicht 1: Gerät
Die Geräteschicht ist der Ort der physischen Steuerung. Loxone Controller und I/O-Module führen lokale Sequenzen aus, lesen Sensoren und steuern Aktoren. Fremdsysteme werden über Gateways oder native Schnittstellen angebunden: BACnet/IP für die Anlagentechnik, Modbus für Zähler und Wechselrichter, KNX für Beleuchtung und Sonnenschutz, DALI für Leuchten, potentialfreie Kontakte für Brandmelde- und Bestandsanlagen.
Die wichtige Entwurfsentscheidung ist nicht, welches Protokoll gewinnt. Sie ist, welcher Controller welche Sequenz besitzt und was passiert, wenn die Supervisionsschicht offline ist. Die lokale Steuerung sollte vollständig genug sein, damit das Gebäude sicher und nutzbar bleibt.
Schicht 2: Supervision
Die Supervisionsschicht ist der Integrationskern. Sie normalisiert jedes Teilsystem in ein gemeinsames Objektmodell: Ein Punkt hat eine Identität, eine Einheit, ein Qualitätsflag, einen Alarmzustand und eine Historie. Eine Tür ist eine Tür, ob sie von einem Zutrittscontroller oder einer PLC kommt. Eine Temperatur ist eine Temperatur, ob sie über BACnet oder Modbus eintrifft.
Hier liegen die systemübergreifenden Verriegelungen. Der Zutritt öffnet einen Raum; Beleuchtung, HLK und Videoüberwachung reagieren. Die Verriegelung wird in der Supervisionsschicht konfiguriert und nicht zwischen Herstellercontrollern fest verdrahtet. Das macht sie sichtbar, testbar und änderbar.
Was die Supervisionsschicht besitzen muss
- Ein einheitliches Alarmmodell mit Priorität, Quittierung und Eskalation.
- Ein Zeitprogrammmodell, das ohne Änderung des Controllercodes übersteuert werden kann.
- Ein Audit-Trail für Befehle, Sollwerte und Quittierungen.
- Ein Historienmodell, das Intervallwerte in bekannter Auflösung speichert.
- Eine Namenskonvention, die die Übergabe übersteht.
Schicht 3: Anwendung
Die Anwendungsebene ist das, was Menschen sehen. Sie sollte für Rollen gebaut sein, nicht für die Demo des Integrators: eine Betreiberansicht, die zeigt, was Aufmerksamkeit braucht, eine Engineer-Ansicht, die Punkte und Trends offenlegt, eine Managementansicht, die Ergebnisse berichtet.
Anwendungen lesen aus dem Supervisionskern. Sie fragen Teilsysteme nicht direkt ab und führen keine eigene Kopie der Wahrheit. Diese Regel verhindert das klassische Fehlerbild, dass Dashboard und BMS unterschiedliche Werte zeigen.
Ein Praxisbeispiel
Ein Mieter betritt um 07:40 ein Stockwerk. Der Zutrittscontroller meldet das Ereignis. Die Supervisionsschicht prüft das Zeitprogramm des Mieters und den Belegungszustand des Stockwerks. Sie aktiviert die Lichtszene, startet die HLK-Sequenz und veranlasst die Videoüberwachung, das Eintrittsereignis zu markieren. Der Betreiber sieht ein Ereignis, nicht vier.
Wenn sich ein systemübergreifendes Verhalten nicht in einem Satz beschreiben lässt, gehört es wahrscheinlich in eine dokumentierte Sequenz und nicht in ein verborgenes Skript.
Was zu spezifizieren ist
| Anforderung | Warum sie wichtig ist |
|---|---|
| Unabhängigkeit der lokalen Steuerung | Das Gebäude muss bei einem Netzwerk- oder Cloud-Ausfall sicher und nutzbar bleiben. |
| Offene Protokollliste | Verhindert, dass ein einzelner Hersteller der einzige Zugang zu den Gebäudedaten wird. |
| Einheitliches Alarmmodell | Verhindert doppelte Alarme und macht die Eskalation prüfbar. |
| Namenskonvention für Punkte | Ermöglicht Übergabe, Wartung und künftige Integration. |
| Historienaufbewahrung und Export | Aussagen zu Energie und Performance brauchen eine belastbare Datenspur. |
Ein Drei-Schichten-Modell ist kein Produktdiagramm. Es ist ein Verantwortungsdiagramm. Wenn Sie nicht sagen können, welche Schicht ein Verhalten besitzt, ist das Verhalten wahrscheinlich am falschen Ort.
Das Fazit
Bei der IBMS-Architektur geht es nicht darum, möglichst viele Systeme zu verbinden. Es geht darum, die Verbindungen nachvollziehbar zu machen: ein Datenmodell, ein Alarmmodell, ein Audit-Trail und eine lokale Steuerung, die das Netzwerk übersteht. Stimmt das, ist das Dashboard einfach. Stimmt es nicht, rettet kein Dashboard das Projekt.
