IBMS
IBMS – integriertes Gebäudemanagementsystem
IBMS erklärt: Wie ein integriertes Gebäudemanagementsystem HLK, Beleuchtung, Zutritt, CCTV, Energie und Brandstatus in einem einheitlichen Betriebsbild zusammenführt.
Was IBMS bedeutet
IBMS steht für integriertes Gebäudemanagementsystem. Es ist eine Integrationsschicht, keine einzelne Controller-Marke. Es sammelt Daten aus dem BMS und aus anderen Gebäudesystemen, normalisiert diese Daten in einem gemeinsamen Modell und gibt Betreibern einen Ort, um Status zu sehen, Alarme zu quittieren und Befehle zu erteilen. Das BMS regelt die Anlage weiterhin; das IBMS koordiniert über Systeme hinweg und berichtet über das Gebäude als Ganzes. Diese Unterscheidung hält die Architektur sauber und verhindert, dass ein Integrationsprojekt zu einem ungeplanten Austausch der Regelungstechnik wird. Diese Grenze zählt auch kommerziell: Ein IBMS sollte nicht zu einem Weg werden, ein funktionierendes BMS ohne separate Entscheidung zu ersetzen. Das IBMS sollte als Integrationsdienstleistung angeboten und kalkuliert werden, nicht als Lizenz mit unspezifiziertem Engineering. Ein klarer Leistungsumfang benennt die Systeme, die Daten, die Regeln und die Betreiberrollen, die die Plattform unterstützen muss.
- Integrationsschicht über dem BMS
- Gemeinsames Daten- und Alarmmodell
- Eine Bedieneransicht über alle Systeme
- BMS behält die Anlagenregelung
Teilsysteme in einem Modell
Ein typischer IBMS-Leistungsumfang umfasst HLK und Anlagen, Beleuchtung, Sonnenschutz, Zutrittskontrolle, CCTV, Einbruchmeldung, Parken, Beschallung, Aufzüge, Energiezähler, Hotelzimmersteuerung und Brandstatus. Jedes Teilsystem behält seinen eigenen Controller und seine eigenen Sicherheitspflichten. Das IBMS liest Status, schreibt zulässige Befehle und verknüpft Ereignisse über Systeme hinweg. Die Integrationsmatrix sollte für jedes Teilsystem angeben, welche Daten schreibgeschützt sind, welche beschreibbar sind und welcher Lieferant für die Anlage verantwortlich bleibt. Diese Matrix ist die praktische Definition des Projekts. Jedes Teilsystem sollte einen benannten Verantwortlichen, ein Schnittstellendokument und ein getestetes Ausfallverhalten haben. Schreibgeschützte Punkte sind keine Einschränkung; sie sind eine Grenze, die Sicherheit und Gewährleistung des Teilsystems schützt. Die Matrix sollte außerdem die Datenrichtung, die Aktualisierungsrate und das Verhalten bei Verbindungsverlust festhalten, denn diese drei Details entscheiden, ob der Betreiber dem Bildschirm vertrauen kann.
- HLK, Beleuchtung und Sonnenschutz
- Zutritt, CCTV und Einbruchmeldung
- Parken, Aufzüge und Beschallung
- Energie, Hotelzimmer und Brandstatus
Alarme, die Betreiber nutzen können
Ein IBMS sammelt Alarme aus Systemen, die nie für gemeinsame Alarmierung ausgelegt wurden. Ohne Rationalisierung entsteht eine Wand aus Lärm. Ein brauchbares Alarmmodell normalisiert Beschreibungen, entfernt Duplikate, ordnet Ereignisse nach Folgen ein, leitet sie an die richtige Rolle weiter und zeichnet Quittierung und Eskalation auf. Kaltwasserausfall, eine aufgezwungene Tür und eine Kommunikationsstörung eines Zählers sollten nicht mit derselben Priorität eintreffen. Die Alarmphilosophie wird während der Planung vereinbart, während der Inbetriebnahme getestet und nach der ersten Betriebssaison überprüft. Der Betreiber sollte sehen können, warum ein Alarm ausgelöst wurde, nicht nur dass er existiert; Kontext ist Teil des Alarms. Alarmzahlen und Wiederholungsereignisse sollten überprüft werden, denn ein lautes System erzieht Betreiber dazu, es zu ignorieren. Eine nützliche Kennzahl ist, wie viele Alarme eine Aktion erfordern; wenn die meisten Störmeldungen sind, braucht das Alarmmodell Arbeit, nicht mehr Bildschirme.
- Normalisierte Alarmbeschreibungen
- Priorisierung nach Folgen
- Weiterleitung, Quittierung und Eskalation
- Alarmprüfung nach der Saison
Verriegelungen und systemübergreifende Logik
Der Wert eines IBMS zeigt sich, wenn Systeme zusammenwirken. Ein Zutrittsereignis, das einen Raum öffnet, kann Beleuchtung, HLK und CCTV in den richtigen Zustand versetzen. Eine Parkeinfahrt kann die Beleuchtung im Anfahrtsbereich einschalten. Ein Brandalarm kann Türen freigeben und RLT-Geräte stoppen, während die Brandmeldezentrale die Steuerhoheit über Sicherheitsfunktionen behält. Verriegelungen sollten als sichtbare Regeln konfiguriert werden, nicht als versteckte Verdrahtung zwischen Lieferantencontrollern. Jede Regel benötigt einen Auslöser, eine Bedingung, eine Aktion, eine Zeitüberschreitung und ein Fehlerverhalten. Tests belegen, dass die Regel funktioniert, und der Audit-Trail zeigt, wer sie geändert hat. Eine Regel, die nicht getestet werden kann, sollte nicht eingesetzt werden, denn das Gebäude wird sich früher oder später auf sie verlassen. Systemübergreifende Regeln sollten in einer definierten Richtung fehlschlagen und das betroffene Teilsystem üblicherweise in seinem lokalen sicheren Zustand belassen. Regeln benötigen außerdem einen Verantwortlichen und ein Prüfdatum; sonst sammeln sie sich an und widersprechen einander.
- Verknüpfung von Zutritt, Beleuchtung und HLK
- Parken und Fassadenbeleuchtung
- Brandbetrieb mit Steuerhoheit der Brandmeldezentrale
- Sichtbare Regeln mit Audit-Aufzeichnungen
Betreibererfahrung
Ein IBMS wird um 02:00 Uhr bewertet, wenn eine Person im Dienst ist und etwas nicht stimmt. Die Oberfläche sollte zeigen, was sich geändert hat, wo es ist, was betroffen ist und was als Nächstes zu tun ist. Rollenbasierte Ansichten halten Betreiber, Techniker und Management mit unterschiedlicher Tiefe auf denselben Daten. Grundrisse, Trends und Alarmhistorie sollten ohne Suche durch Menüs erreichbar sein. Mobiler Zugriff hilft einem kleinen Team, einen großen Standort abzudecken. Schulung und Dokumentation sind Teil des Produkts, kein Nachgedanke. Eine nützliche Prüfung ist, dass eine mit dem Projekt nicht vertraute Person eine Routineaufgabe ohne Hilfe abschließen kann. Ansichten sollten um Rollen und Aufgaben herum gestaltet sein, nicht um die Menüstruktur des Lieferanten. Die Oberfläche sollte außerdem einen Messwert von einem veralteten Wert unterscheiden, denn ein Bildschirm, der live aussieht, aber alte Daten zeigt, ist schlimmer als kein Bildschirm.
- Klare Hierarchie und Drill-down
- Rollenbasierte Ansichten und Berechtigungen
- Trends, Grundrisse und Alarmhistorie
- Schulung und Betreiberdokumentation
Offene Protokolle und Local-First-Regelung
IBMS hängt von Schnittstellen ab. BACnet/IP und Modbus sind üblich für Anlagen und Zähler, KNX für Beleuchtung und Raumregelung, DALI für Leuchten, APIs und ODBC für Geschäftssysteme sowie potentialfreie Kontakte für Geräte, die nichts anderes anbieten. Die Plattform sollte im lokalen Netzwerk laufen, die Historie vor Ort halten und Fernzugriff als Option mit Authentifizierung und Protokollierung behandeln. Die Netzwerksegmentierung zwischen OT und IT ist Teil des Entwurfs. Der Eigentümer sollte den Integrator wechseln können, ohne das Punktmodell, die Grafiken und die Daten zu verlieren. Die Dokumentation sollte Netzwerkdiagramm, Punktmodell und Lizenzsituation enthalten, damit der Eigentümer nicht an einen Lieferanten gebunden ist. Fernzugriff sollte widerrufbar sein, ohne den lokalen Betrieb zu stören. Local-First bedeutet nicht isoliert: Es bedeutet, dass das Gebäude weiterläuft, wenn die Weitverkehrsverbindung ausfällt, und der Betreiber die Daten vor Ort weiterhin erreichen kann.
- BACnet, Modbus, KNX und DALI
- APIs und ODBC für Geschäftssysteme
- Lokale Server und Historie
- Segmentierung und auditierter Fernzugriff
Architektur, Netzwerke und Cybersicherheit
Ein IBMS ist ebenso ein Netzwerkprojekt wie ein Regelungstechnikprojekt. Integrationsserver, Gateways und Bedienerclients liegen in einem segmentierten Netzwerk; Gebäudetechnik sollte sich kein flaches Netzwerk mit der Büro-IT teilen. Ein üblicher Entwurf nutzt ein eigenes OT-VLAN, eine Firewall zwischen OT und IT und einen kontrollierten Fernzugriff über VPN oder Broker mit Multi-Faktor-Authentifizierung. Zeitabgleich ist wichtig, weil Alarme und Trends aus verschiedenen Systemen zusammenpassen müssen; ohne konsistente Zeitquelle wird die Ereigniskorrelation zur Vermutung. Speicherung der Historie, Backup und Wiederherstellung sollten spezifiziert werden, einschließlich Aufbewahrungsdauer und wer Daten exportieren darf. Benutzerkonten sollten nach Möglichkeit aus einem Verzeichnis kommen, mit rollenbasierten Berechtigungen und einem Audit-Log für Befehle und Sollwertänderungen. Fernzugriff sollte widerrufbar sein, ohne den lokalen Betrieb zu stören. Cybersicherheit ist kein Produktmerkmal, das am Ende ergänzt wird; sie ist Teil der Integrationsarchitektur.
- OT- und IT-Segmentierung
- Konsistenter Zeitabgleich
- Rollenbasierte Konten und Audit-Logs
- Backup, Aufbewahrung und Fernzugriffsrichtlinie
Abwicklungsphasen und häufige Fehlerbilder
Die Abwicklung folgt einer Reihenfolge. Ein Audit bestätigt Systeme, Versionen und verfügbare Schnittstellen. Eine Integrationsmatrix definiert Lese- und Schreibrechte, Verantwortliche und Grenzen. Ein Punktmodell gibt jedem Element Namen, Einheit, Berechtigung und Alarmpriorität. Gateways und Schnittstellen werden nach Möglichkeit im Werk und anschließend vor Ort konfiguriert und getestet. Die Inbetriebnahme geht von Punkt-zu-Punkt-Prüfungen zu systemübergreifenden Regeln und Fehlertests über und endet mit einer Soft-Landing-Phase, in der Betreiber das System unter realen Bedingungen nutzen. Die Dokumentation umfasst Netzwerkdiagramm, Punktmodell, Integrationsmatrix, Testprotokolle, Lizenzsituation und Wiederherstellungsverfahren. Häufige Fehlerbilder sind vorhersehbar: eine API, die angenommen, aber nie getestet wurde; Alarmfluten, die das eigentliche Ereignis verbergen; veraltete Daten aus einem Gateway; doppelte Punktnamen; Zeitdrift zwischen Systemen und ein Lizenzmodell, das den Eigentümer daran hindert, Punkte ohne den ursprünglichen Lieferanten hinzuzufügen.
- Audit und Integrationsmatrix
- Punktmodell und Gateway-Tests
- Systemübergreifende Tests und Fehlertests
- Soft Landing und As-built-Unterlagen
IBMS-Integrationsmatrix
18 rows| Teilsystem | Typische Schnittstelle | IBMS-Rolle | Grenze |
|---|---|---|---|
| HLK und BMS | BACnet/IP, Modbus, 0–10 V | Zeitprogramme, Sollwerte, Alarme, Trends | BMS behält die Anlagenregelung |
| Beleuchtung | DALI, KNX, Relais | Szenen, Belegung, Störungsstatus | Beleuchtungscontroller behält lokale Regelung |
| Sonnenschutz | KNX, Modbus, potenzialfreie Kontakte | Sonnen- und Windregeln, Szenen | Motor- oder Fassadencontroller behält Grenzwerte |
| Zutrittskontrolle | API, OSDP über Controller, potenzialfreie Kontakte | Türstatus, Freigabe, Ereignisverknüpfung | Zutrittssystem behält Berechtigungslogik |
| CCTV | ONVIF oder Hersteller-API | Kamerakarte, Ereignisverknüpfung, Zustandsstatus | VMS behält Aufzeichnung und Aufbewahrung |
| Einbruchmeldeanlage | Potenzialfreie Kontakte, API | Zonenstatus, Scharf-/Unscharf-Ereignisse | Einbruchmelderzentrale behält die Auswertelogik |
| Brandmeldeanlage | Potentialfreie Kontakte, überwachte Eingänge | Nur Status, Voralarm und Verknüpfung | Brandmelderzentrale behält die Letztverantwortung für den Personenschutz |
| Entrauchung | Potenzialfreie Kontakte, API | Status und Klappenstellung | Entrauchungsanlage behält ihre Ablaufsequenz |
| Parken | API, TCP/IP | Einfahrtsstatus, Stellplatzbelegung, Ausnahmen | Parksystem behält die Schrankensteuerung |
| Beschallung | API, potenzialfreie Kontakte | Zonenstatus, zeitgesteuerte Durchsagen | ELA-Anlage behält die Notfallpriorität |
| Aufzüge | Potenzialfreie Kontakte, API | Status-, Störungs- und Alarmsignale | Aufzugssteuerung behält die Fahrtsicherheit |
| Energiezähler | Modbus, M-Bus über Gateway, Impulse | Unterzählung, Referenzwerte, Zuordnung | Messsystem behält die Tarifdaten |
| Wasser- und Gaszähler | Modbus, M-Bus über Gateway, Impulse | Verbrauchstrends und Leckalarme | Versorgungszählung behält die Abrechnungsdaten |
| Ladeinfrastruktur | OCPP, Hersteller-API | Ladevorgangsstatus, Laststeuerung, Ausnahmen | Betreiber der Ladeinfrastruktur behält Abrechnung und Sicherheit |
| USV und Generatoren | SNMP, Modbus, potenzialfreie Kontakte | Betriebsstunden, Kraftstoffstatus, Umschaltvorgänge | Stromversorgung behält die Umschaltlogik |
| Hotelzimmer und PMS | API, ODBC, RCU-Schnittstelle | Check-in-/Check-out-Ereignisse, Zimmerstatus, Energiegrenzen | PMS behält Reservierungen und Abrechnung |
| Besucherverwaltung | API, potenzialfreie Kontakte | Vorregistrierungsstatus, Türereignisse | Besuchersystem behält die Identitätsprüfung |
| Gebäudeanalytik und FDD | Historian-API, Datenbankexport | Fehlererkennung, Referenzwerte, Performance-Berichte | Analyseebene behält ihre Modelle |
Projektbilder
3 images
Häufige Fragen
01Was ist ein IBMS?
Ein integriertes Gebäudemanagementsystem verbindet Gebäudeteilsysteme in einem gemeinsamen Datenmodell, einer gemeinsamen Alarmliste und einer gemeinsamen Bedieneransicht. Es ergänzt systemübergreifende Regeln und Berichte, während jedes Teilsystem seine eigene Steuerung und seine Sicherheitsaufgaben behält.
02Worin unterscheidet sich ein IBMS von einem BMS?
Ein BMS steuert und überwacht die Gebäudetechnik, insbesondere HLK und Anlagen. Ein IBMS liegt darüber und integriert das BMS mit Zutrittskontrolle, CCTV, Parken, Energie, Hotelzimmern und Brandstatus. Das BMS bleibt die Steuerungsebene.
03Müssen wir unser bestehendes BMS ersetzen?
Nein. Üblicherweise wird das bestehende BMS über BACnet, Modbus oder eine andere verfügbare Schnittstelle integriert. Ein Ersatz ist eine separate wirtschaftliche Entscheidung und keine Voraussetzung für ein IBMS.
04Kann ein IBMS ohne Internet betrieben werden?
Ja. Integrationsplattform und Steuerungslogik sollten im lokalen Netzwerk laufen, die Historie wird vor Ort gespeichert. Internetzugang ist optional – für Fernunterstützung und Berichte.
05Welche Protokolle unterstützt ein IBMS?
Übliche Schnittstellen sind BACnet/IP, Modbus RTU und TCP, KNX, DALI, APIs, ODBC und potenzialfreie Kontakte. Der tatsächliche Umfang hängt von der installierten Ausrüstung und den für das Projekt gewählten Gateways ab.
06Wie werden Brandalarme behandelt?
Die Brandmeldeanlage bleibt ein eigenständiges System für den Personenschutz. Das IBMS liest Status- und Voralarmsignale über potenzialfreie Kontakte oder überwachte Eingänge und kann definierte Verknüpfungen auslösen; die Brandmeldezentrale behält jedoch jederzeit die Hoheit.
07Wie werden Alarme priorisiert?
Alarme werden normalisiert, entdupliziert und nach ihrer Auswirkung eingestuft, nicht nach dem Quellsystem. Die Alarmphilosophie legt Priorität, Weiterleitung, Quittierung und Eskalation fest und wird bei der Inbetriebnahme getestet.
08Kann ein IBMS mehrere Gebäude abdecken?
Ja. Lokale Steuerungen können die einzelnen Gebäude betreiben, während eine zentrale Ebene Alarme, Energie und Berichte zusammenführt. Die Planung sollte festlegen, was lokal bleibt und was vom Netzwerk zwischen den Standorten abhängt.
Nächster Schritt
Bringen Sie uns das Gebäude.
Nennen Sie uns Gebäudetyp, Systeme im Leistungsumfang und das benötigte Ergebnis. Wir zeigen den kürzesten Weg zu einem funktionierenden System.