
IBMS · Architektur
IBMS-Architektur – ein Referenzmodell, das die Übergabe übersteht
Eine Referenzarchitektur für ein IBMS: Feldgeräte, eine Netzwerk- und Gateway-Schicht, ein Leittechnik-Kern mit einem einheitlichen Datenmodell und rollenbasierte Anwendungen.
Kurze Antwort
Eine IBMS-Architektur hat vier Schichten: Feldgeräte und Controller, die Netzwerk- und Gateway-Schicht, einen Leittechnik-Kern mit einem einheitlichen Datenmodell und rollenbasierte Anwendungen. Die Steuerung bleibt lokal, die Integrationslogik liegt im Kern, und Anwendungen lesen aus ihm, statt Teilsysteme direkt abzufragen.
Vier Schichten, eine verbindliche Datenbasis
Betrachten Sie die Architektur als vier Schichten. Feldgeräte messen Zustände und betätigen Stellglieder. Controller führen lokale Sequenzen aus. Die Netzwerk- und Gateway-Schicht transportiert Daten zwischen Protokollen und Netzwerken. Der Leittechnik-Kern normalisiert Punkte in ein einheitliches Objektmodell und verantwortet Alarme, Zeitprogramme, Historie und Verriegelungen. Anwendungen sitzen darüber und stellen rollenspezifische Sichten bereit. Die Schichten sind durch Verantwortlichkeiten definiert, nicht durch Produktnamen. Ein einzelnes Gerät kann in einem kleinen Gebäude zwei Schichten übernehmen, doch die Verantwortlichkeiten sollten dennoch schriftlich festgehalten werden, denn genau das macht das System nach dem Ausscheiden des Projektteams prüfbar und wartbar. Wird eine Schicht übersprungen, erscheint die fehlende Verantwortung üblicherweise als manuelle Routine wieder. Schreiben Sie die Verantwortung neben jedes Gerät im Plan.
Die Netzwerk- und Gateway-Schicht
Die meisten Integrationsfehler beginnen hier. BACnet/IP, Modbus TCP, KNX und DALI haben jeweils eigene Zeitverhalten, Adressierungs- und Diagnosemodelle. Halten Sie das Gebäudenetz vom Unternehmensnetz getrennt, dokumentieren Sie jedes Gateway mit seiner Punktzuordnung und vermeiden Sie gestapelte Übersetzer. Ein Gateway sollte ein Protokoll übersetzen und keine Steuerungssequenz verantworten. Wo ein Teilsystem eine stabile API bereitstellt, nutzen Sie diese direkt; wo nicht, legen Sie Gateway-Verantwortlichen, Stromversorgung, Firmware-Strategie und Fehlerverhalten fest. Netzwerkpläne, die nach der Inbetriebnahme gezeichnet werden, sind ein Warnsignal, kein Liefergegenstand. Führen Sie eine Portliste und einen Adressplan; die Inbetriebnahme ist schneller, wenn die Zuordnung stimmt. Ein Gateway, das einen Laptop und ein Passwort erfordert, das niemand hat, ist keine offene Schnittstelle.
Der Leittechnik-Kern
Im Kern wird aus dem IBMS mehr als eine Sammlung von Konnektoren. Jeder Punkt benötigt eine Identität, eine Einheit, ein Qualitätskennzeichen, eine Historienstrategie und eine Alarmklasse. Jedes Teilsystem benötigt eine Namenskonvention, die ein neuer Ingenieur lesen kann. Zeitprogramme und Verriegelungen gehören hierher, damit sie sichtbar, testbar und ohne Änderung von Herstellercode anpassbar sind. Der Kern verantwortet außerdem Zeitabgleich, Benutzerrollen und Audit-Trail. Wenn zwei Anwendungen unterschiedliche Werte für dieselbe Größe liefern, ist der Kern der Ort, an dem das geklärt wird – nicht eine dritte Datenbank, die vom Berichtsteam gepflegt wird. Punktnamen sollten Gerät, Standort und Funktion in dieser Reihenfolge beschreiben. Ein Name, den nur der ursprüngliche Programmierer versteht, ist ein künftiger Serviceeinsatz.
Resilienz und Sicherheit von Anfang an
Die lokale Steuerung muss einen Ausfall der Leittechnik, eine Netzwerkstörung und einen Serverneustart überstehen. Das bedeutet, dass Controller ihre Sequenzen und sicheren Stellungen halten und das Netzwerk ein dokumentiertes Fehlerverhalten hat. Sicherheit ist Teil derselben Planung: segmentierte VLANs, benannte Konten, minimale Rechte, Patchmanagement, Protokollierung und ein kontrollierter Fernzugriffsweg. Sicherungen sollten durch den Auftraggeber wiederherstellbar sein, nicht nur durch den ursprünglichen Integrator. Testen Sie die Ausfallszenarien während der Inbetriebnahme, denn eine Architektur, die nie absichtlich zum Ausfall gebracht wurde, ist noch immer nur eine Zeichnung. Dokumentieren Sie die Wiederherstellungsschritte und testen Sie sie mit dem Team des Auftraggebers, nicht nur mit dem Laptop des Installateurs. Eine Sicherung, die nie wiederhergestellt wurde, ist eine Hoffnung, keine belastbare Maßnahme.
IBMS-Schichten und Verantwortlichkeiten
5 rows| Ebene | Verantwortet | Planungsfrage |
|---|---|---|
| Feld | Messung und Stellgliedansteuerung | Sind Sensorpositionen und Ausfallstellungen definiert? |
| Controller | Lokale Sequenzen und Sicherheit | Was läuft bei Netzausfall weiter? |
| Netzwerk und Gateway | Protokollübersetzung und Transport | Wer verantwortet jedes Gateway und seine Punktzuordnung? |
| Leittechnik-Kern | Datenmodell, Alarme, Historie, Verriegelungen | Gibt es eine einheitliche Identität für jeden Punkt? |
| Anwendung | Rollenbasierte Sichten und Berichte | Liest sie aus dem Kern oder fragt sie Teilsysteme ab? |
Projektbilder
3 images


Häufige Fragen
01Wie viele Schichten benötigt eine IBMS-Architektur?
Drei oder vier, je nachdem, ob das Netzwerk separat gezählt wird. Entscheidend ist, dass jede Schicht einen Verantwortlichen und ein klares Fehlerverhalten hat, nicht die Anzahl selbst.
02Wo sollten Gateways in der Architektur sitzen?
Am Feldrand, nahe am Teilsystem, das sie übersetzen, in einem dokumentierten Netzsegment. Sie sollten keine Steuerungslogik tragen und nicht zu einem undokumentierten Single Point of Failure werden.
03Kann das IBMS in der Cloud laufen?
Die Anwendungsschicht kann es, und häufig tut sie es. Leittechnik und lokale Steuerung sollten vor Ort bleiben, damit das Gebäude weiterläuft, wenn die Verbindung abbricht.
04Wie sollte mit Cybersicherheit umgegangen werden?
Segmentieren Sie Netzwerke, verwenden Sie benannte Konten mit minimalen Rechten, patchen Sie in einem definierten Zyklus, protokollieren Sie administrative Aktionen und kontrollieren Sie den Fernzugriff. Das sind Planungsanforderungen, keine nachträgliche IT-Überlegung.
05Welches Dokument definiert die Architektur?
Ein Netzwerk-Strangschema, eine Punktliste, eine Protokollmatrix und eine Verantwortungsmatrix. Zusammen zeigen sie, was womit verbunden ist, wer jede Schnittstelle verantwortet und wie sie geprüft wird.
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.